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ABSTRACT 


The  U.S.  Coast  Guard  has  been  continuously  asked  to  perform 
more  missions  with  less  resources.  Technological  advcunces  in 
telecommunications  eind  information  systems  accessibility  have  played  a 
major  role  in  the  Coast  Guard  meeting  these  challenges.  However,  to 
meet  new  demands  for  even  greater  efficiency  and  effectiveness,  the 
Coast  Guard  strategy  for  tighter  interoperability  between  Coast  Guard 
commands  must  continue  to  evolve.  To  support  this  evolution,  the 
Command,  Control,  and  Communication  Branch  of  the  Coast  Guard 
must  use  a  strategy  for  project  management  that  will  foster  greater 
efficiency  and  effectiveness.  This  strategy  should  include  a  standardized 
approach  to  project  management  that  fosters  communication,  attention 
to  detail,  and  leads  to  interoperability  of  systems  through 
standardization  without  extensively  limiting  creativity  or  use  of 
technological  advances. 

This  paper  demonstrates  how  the  use  of  systems  thinking,  and  in 
particular  the  Structured  Approach  Model,  can  encourage  the 
management  characteristics  that  will  lead  to  the  development  of  more 
effective  telecommunications  projects  and  completion  of  those  projects  in 
a  more  efficient  manner.  This  paper  explains  the  seven  phases  of  the 
Structured  Approach  Model  and  views  each  using  the  functional, 
organizational,  and  physical  prospectives.  Steps  for  appl)dng  the  model 
are  given  and  are  aimed  at  the  Coast  Guard  project  officer. 
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I.  INTRODUCTION 


A.  PURPOSE 

The  purpose  of  this  thesis  is  to  outline  a  structured  approach  to 
assist  US  Coast  Guard  project  officers  in  developing  and  planning  a 
major  telecommunications  system  replacement  project.  This 
methodology  will  provide  processes  to  support  the  project  officer  in 
soliciting,  documenting,  and  tracking  project  requirements  using  a 
“systems  approach.”  This  thesis  will  develop  methods  for  completing  a 
baseline  assessment,  developing  a  target  architecture,  and  selecting  a 
migration  path  from  available  alternative  technologies.  The  selection 
process  will  include  a  cost-effectiveness  analysis. 

The  replacement  project  for  the  Coast  Guard’s  Bay  Area 
Communications  System  (BACS)  in  the  San  Francisco  area  will  be  used 
to  illustrate  the  application  of  this  methodology.  Where  actual  data  is 
not  available,  assumptions  (or  estimates)  will  be  used  for  the  express 
purpose  of  illustrating  the  methodology. 

The  purpose  of  this  thesis  is  NOT  to  recommend  a  particular 
alternative  for  the  BACS  replacement  project.  The  purpose  is  to  provide  a 
methodology  that  encourages  project  officers  to  plan  and  develop  their 
projects  using  a  systems  view  and  provide  a  number  of  processes  and 
procedures  they  can  use  in  doing  so. 

The  primary  research  questions  for  this  thesis  included; 

1 .  How  can  the  structured  approach  model  be  used  to  ensure  all 
aspects  of  the  project  are  considered? 

2.  How  can  the  existing  functional  requirements  and  any  new 
functional  requirements  expected  to  arise  over  the  new  system’s 
life-cycle  be  gathered  and  documented? 
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3.  How  can  we  track  the  functional  requirements  for  each  site,  the 
physical  capacities  for  each  site,  and  the  technological 
alternatives  that  can  most  effectively  meet  these  constraints? 

4.  Once  the  alternatives  for  each  site  have  been  documented,  how 
can  we  choose  the  most  cost  effective  alternative? 

a)  What  criteria  should  be  used  to  select  the  alternatives? 

b)  How  shoiild  the  chosen  criteria  be  weighted  for 
comparison? 

c)  Who  should  develop  the  criteria  weights? 

5.  What  types  of  resistance  to  change  may  arise? 

6.  What  can  be  done  to  overcome  resistance  to  change? 

B.  DISCUSSION 

We  live  in  an  era  of  very  complex  technologies  and  system 
interdependencies.  To  cover  all  the  bases,  a  project  officer  must  consider 
a  project  from  many  different  aspects.  Appl5dng  an  existing  list  of  project 
considerations  is  not  sufficient,  for  every  project  is  unique  in  some 
manner.  A  solution  rests  in  the  use  of  “systems  thinking”  concepts  and 
appl5dng  a  model  that  provides  an  analytical  framework  on  which  project 
officers  can  build  their  own  list  of  considerations.  The  structured 
approach  model  provides  such  a  framework  for  managing  a  project  from 
conception  of  customer  goals  to  maintaining  the  system  after 
installation.  This  thesis  will  focus  on  the  planning  and  development 
stages  of  the  structured  approach  model. 

A  Coast  Guard  project  officer  for  a  telecommunications  project  has 
even  more  complex  job  than  most  other  project  officers. 
Telecommunications  are  a  part  of  our  basic  infrastructure.  Changes  to 
the  infrastructure  affect  many  different  entities,  including  those  in  both 
operational  and  support  roles;  therefore,  changes  to  the  infrastructure 
should  be  undertaken  as  infrequently  as  possible.  For  this  to  occur,  the 
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infrastructure  must  be  designed  to  meet  the  users’  needs  today  and  be 
designed  to  migrate  to  meet  future  needs,  with  as  little  disruption  to  the 
user  as  possible. 

This  takes  proper  planning  and  a  great  deal  of  knowledge, 
cooperation,  and  coordination.  The  user  understands  what  must  be 
done  to  complete  the  missions,  but  the  project  officer  is  the  technical 
expert.  The  user  must  help  the  project  officer  understand  every  process 
used  to  complete  the  mission.  The  project  officer  must  educate  the  user 
as  to  how  technology  can  help  him  more  effectively  complete  the  mission. 
Together,  they  must  paint  a  picture  of  the  users  systems,  as  they  exist 
today,  and  how  they  may  change  in  the  future.  This  evaluation  of  the 
users  systems  must  all  take  place  before  any  changes  to  the  supporting 
telecommunications  system  can  even  be  considered.  In  other  words,  how 
can  the  project  officer  design  a  supporting  infrastructure  if  it  is  not 
understood  what  needs  to  be  supported? 

This  thesis  steps  through  the  phases  of  the  structured  approach 
model  only  once.  But  it  should  be  understood  that  a  minimum  of  two 
iterations  of  this  model  should  be  completed:  once  to  cover  the  users 
systems  that  ride  on  the  telecommunications  system  and  once  for  the 
telecommunications  system  itself. 

The  Bay  Area  Communications  System  (BAGS)  replacement  project 
is  an  optimal  project  for  illustration  purposes.  It  contains  most  of  the 
challenges  faced  when  replacing  a  major  telecommunications  system.  It 
spans  some  25  sites  spread  over  hundreds  of  miles  and  is  located  in  both 
urban  and  rural  areas.  It  has  at  least  12  customer  commands, 
sponsored  by  numerous  headquarters’  and  pacific  area  entities.  Site 
signal  demands  run  the  gamut  from  a  few  analog  signals  to  multiple  T- 
I’s. 
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C.  BACKGROUND 


The  Coast  Guard  first  installed  the  Bay  Area  Communications 
Microwave  System  between  1985-1987.  This  system  connected  20 
different  sites  using  19  analog  microwave  links.  It  was  designed  to  meet 
the  Coast  Guard  wide  area  networking  (WAN)  needs,  within  the  San 
Francisco  area,  that  existed  at  the  time.  The  reasons  the  Coast  Guard 
cited  when  justifying  the  construction  of  the  BAGS  system  [Ref.  1,  p.  80] 
were  to: 

1.  improve  reliability  and  transmission  quality  for  voice  and  data 
telephone  circuits  within  the  San  Francisco  Bay  area; 

2.  provide  all  the  commands  ("units")  subordinate  to  USCG  Group 
San  Francisco  with  the  capability  to  directly  communicate  with 
ships,  boats,  aircraft,  and  personnel  throughout  the  bay  area; 

3.  provide  an  alternate  routing  to  deliver  textual  message  traffic 
between  the  communications  station  at  Point  Reyes,  and  the 
district  office; 

4.  replace  existing  UHF  links  between  the  communications  station 
at  Point  Reyes  and  the  communications  center  at  Coast  Guard 
Island,  Alameda; 

5.  replace  existing  UHF  links  between  the  transmitter  and  receiver 
sites  at  the  communications  station; 

6.  reduce  FTS  (Federal  Telephone  System)  and  commercial 
telephone  system  recurring  costs; 

7.  provide  FTS  access  to  all  bay  area  units; 

8.  significantly  improve  communications  in  the  bay  area  at  a  lower 
total  life-cycle  cost; 

9.  provide  AUTO  VON  access  at  a  lower  cost. 

As  the  Coast  Guard  WAN  requirements  have  changed  over  the  past 
decade,  at  least  six  major  leased  lines  have  been  added  to  the  system 
and  one  microwave  link  has  been  removed.  The  system  is  now  referred  to 
as  BAGS  and  connects  25  different  sites.  Appendix  A  contains  a  chart 
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depicting  the  geographic  location  and  inter-connection  of  the  sites  served 
by  this  system.  The  BAGS  interconnects  at  least  12  different  Coast 
Guard  units  which  have  mission-related  communications  requirements. 

The  Bay  Area  Communications  System  must  be  replaced  for  three 
reasons[Ref.2:  p.  2]: 

1.  the  microwave  links  were  built  in  the  mid  1980’s  and  are 
becoming  expensive  to  maintain; 

2.  the  frequency  allocations  for  the  2  GHz  microwave  are  to  be 
reallocated  to  meet  growing  civilian  frequency  needs; 

3.  customer  requirements  have  changed  and  are  no  longer  being 
met  by  the  existing  system. 
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II.  SYSTEMS  THINKING  AND 


THE  STRUCTURED  APPROACH  MODEL 


A.  SYSTEMS  THINKING 

1.  Introduction 

Systems  thinking  has  been  evolving  over  the  course  of  the 
twentieth  century  and  is  used  in  fields  as  diverse  as  physical  and  social 
sciences,  engineering,  and  management[Ref.  6,  p.  68].  Over  this  period, 
countless  tools  and  techniques  have  been  developed.  Therefore,  the 
scope  of  this  chapter  must  be  limited  to  presenting  the  reader  with  a 
broad  picture  of  “systems  thinking.”  The  intention  of  this  chapter  is  to: 

1 .  emphasize  to  the  reader  the  importance  of  practicing  systems 
thinking; 

2.  assist  the  reader  in  understanding  some  of  the  basic  principles 
of  systems  thinking; 

3.  generate  enough  interest  that  the  reader  will  perform  further 
independent  study  of  the  principles  of  systems  thinking.  For 
highly  recommended  reading  material  on  the  subject  of  systems 
thinking,  see  Ref.  3.  and  Ref.  6. 

2.  What  is  Systems  Thinking? 

To  understand  systems  thinking,  we  must  first  define  a  system. 
The  Webster’s  dictionary  [Ref.  4,  p.  1 199]  defines  a  system  as,  “A 
regularly  interacting  or  interdependent  group  of  items  forming  a  unified 
whole.  Our  world  is  made  up  of  systems.  As  these  systems  interact,  they 
create  an  even  larger,  more  complex,  system.”  For  example,  the  BAGS 
system  consists  of  a  microwave  system  and  leased  lines  which  interact 
together  [Ref  5,  p.  1-1].  BAGS  can  also  be  viewed  as  part  of  the  Goast 
Guard  telecommunications  system  used  to  communicate  with  internal 
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and  external  entities.  Viewed  in  this  context,  the,  scope  for  designing  an 
efficient  system  greatly  increases  in  both  detail  complexity  and  d3mamic 
complexity.  Detail  complexity  exists  when  many  variables  must  be 
considered.  D5mamic  complexity  exists  when  any  of  the  following  occur 
[Ref.  6,  p.  71]: 

1.  when  the  same  action  has  dramatically  different  effects  in  the 
short  run  compared  to  the  long; 

2.  when  an  action  has  one  set  of  consequences  locally  and  a  veiy 
different  set  of  consequences  in  another  part  of  the  system; 

3.  when  obvious  interventions  produce  nonobvious  consequences. 

Systems  thinking  is  basically  the  art  of  understanding  how  system 
entities  interact.  Peter  Senge  [Ref.  6,  p.  6]defines  system  thinking  as: 

“a  discipline  for  seeing  wholes.  It  is  a  framework  for  seeing 
interrelationships  rather  than  things,  for  seeing  patterns  of  change  rather  than 
static  “snapshots.”  It  is  a  set  of  general  principles...a  discipline  for  seeing  the 
“structures”  that  underlie  complex  situations,  and  for  discerning  high  from  low 
leverage  change.” 

Systems  thinking  consists  of  principles  and  practices.  The 
principles  help  us  to  understand  the  basic  causes  for  resistance  to 
change  within  a  system.  The  practices,  or  tools,  help  us  to  understand 
the  dynamics  at  work  within  a  system  and  find  leverage  points  that  can 
bring  about  change. 

3.  How  Can  it  Help  the  Coast  Guard? 

The  Coast  Guard  is  structured,  in  a  hierarchical  manner,  like 
many  other  bureaucratic  institutions,  with  commands,  divisions, 
branches,  and  so  on.  Each  with  specific  areas  of  responsibility  and 
expertise.  This,  however,  tends  to  lead  to  a  kind  of  assembly  line 
mindset.  We  take  what  is  given  to  us,  apply  our  expertise,  and  hand  it 
off  to  the  next  one  in  line.  This  is  done  with  very  little  forethought  of  how 
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our  actions  siffect  the  actions,  and  work,  of  others.  We  rarely  feel  that  we 
can  bring  changes  to  “the  system,”  so  we  continue  doing  our  part  and 
blame  the  rest  of  the  system  for  existing  inefficiencies. 

For  example,  suppose  that  a  leased  line  is  required  for  a  new 
system.  The  project  officer  requests  the  line,  the  telecommunications 
officer  orders  the  line,  and  the  financial  officer  pays  it.  However,  there  is 
no  mechanism  to  tract  the  leased  line  through  its  life-cycle.  The 
Maintenance  85  Logistics  Center  (MLC)  continues  to  pay  for  the  line  as 
long  as  it  appears  on  the  phone  bill.  In  one  instance  Maintenance  & 
Logistics  Center  Pacific  (MLCP)  found,  by  chance,  that  they  had  been 
continuously  paying  for  four  leased  lines  that  had  been  disconnected  six 
months  earlier  [Ref  7].  In  this  example,  each  person  did  his  job  as 
assigned,  but  the  system  was  not  taken  into  consideration.  When  we 
look  from  each  perspective  view  point,  everything  seems  fine;  but  when 
looking  at  the  system  as  a  whole,  and  the  outcome,  it  is  obvious  that  the 
system  needs  fixing. 

4.  Who  Should  Apply  it? 

As  leaders  in  the  CG,  we  must  encourage  everyone  associated  with 
the  CG  to  practice  systems  thinking.  We  must  take  the  time  to  evaluate 
the  ideas  and  issues  that  are  raised,  independent  of  who  raises  them. 

Programs  such  as  Ideas  Express  are  great  motivational  tools  to 
encourage  the  raising  of  ideas.  Additional  programs  which  may  raise  the 
level  of  systems  thinking  should  be  carefully  considered;  however, 
nothing  will  work  better  than  a  boss  willing  to  take  the  time  to  listen  and 
evaluate. 
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5.  Conclusion 

The  purpose  of  this  section  is  to  encourage  others  to  independently 
study  and  apply  systems  thinking.  In  these  times  of  shrinking  budgets, 
systems  thinking  is  essential  if  we  are  to  reach  the  levels  of  efficiency  and 
effectiveness  demanded  of  us. 

B.  STRUCTURED  APPROACH  MODEL 

1.  Introduction 

Any  large  design  project  has  many  engineering  and  management 
considerations  which  must  be  tracked  in  a  project  file  as  the  project 
moves  forward.  This  involves  both  detail  complexity  and  dynamic 
complexity.  The  procedures  used  in  this  paper  are  organized  using  the 
structured  approach  model  as  seen  in  Figure  1 .  The  structured 
approach  model  assists  the  design  team  by  organizing  the  major  phases 
to  be  completed  over  the  system’s  life-cycle.  This  aids  in  tracking  project 
details  that  have  been  examined.  The  model  encourages  the  design  team 
to  look  at  the  system  from  different  perspectives.  These  perspectives  form 
the  framework  for  viewing  the  project  in  a  “systems  thinking”  manner. 
This  encourages  the  design  team  to  consider  the  whole  system  during 
each  project  phase. 

2.  The  Structured  Approach  Model 

The  model  consists  of  eight  phases  (exterior)  and  three  perspectives 
(interior).  The  model  breaks  the  project’s  life-cycle  into  eight  phases, 
starting  with  “organize  and  plan”  and  finishing  with  “maintain  system 
process.”  Each  phase  is  viewed  using  the  three  perspectives:  1) 
Functional,  2)  Organizational,  and  3)  Physical.  Following  is  a  general 
definition  of  each  of  these  perspectives,  or  views  [Ref.  2,  Module  2]: 
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Functional:  The  Functional  perspective  helps  systems  engineers  and  managers 
understand  systems  by  examining  and  describing  the  functions  that  systems  must  perform 
to  meet  system  requirements. 

Organizational:  The  Organizational  perspective  helps  systems  engineers  and  managers 
understand  systems  by  examining  and  describing  the  configuration  and  the  coordination 
required  for  systems  to  function  effectively  and  efficiently. 

Physical:  The  Physical  perspective  helps  systems  engineers  and  managers  understand 
systems  by  examining  and  describing  the  physical  resources  required  by  systems  to 
perform  their  functions. 


The  structured  approach  model  is  based  on  the  model 
recommended  in  Volume  four  of  the  Department  of  Defense  Technical 
Architecture  Framework  of  Information  Management  (TAFIM), 
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Architecture  Concepts  and  Design  Guidance.  The  TAFIM  model  differs 
from  the  structured  approach  model  by  breaking  the  project  into  seven 
phases,  instead  of  eight,  and  does  not  take  advantage  of  the  perspective 
framework  (interior).  In  the  author’s  opinion,  the  inclusion  of  the 
perspective  framework  is  the  distinct  advantage  of  the  structured 
approach  model.  It  requires  the  design  team  to  consider  the  whole 
system  during  each  phase  of  the  project. 

3.  How  Can  it  Help  the  Coast  Guard? 

Two  major  problems  faced  by  project  officers  when  dealing  with 
large  projects  include  1)  justifying  the  decisions  made  by  the  design 
team,  and  2)  historically  recording  these  decisions  and  the  reasoning 
behind  them.  Large  projects  normally  last  for  years,  from  conception  to 
completion.  Due  to  military  rotations  and  other  factors,  personnel 
turnovers  can  occur  in  both  the  design  team  and  the 
reviewing/ approving  hierarchy.  With  these  turnovers,  information 
pertaining  to  the  decisions  made  may  be  lost  if  not  documented  properly. 

Following  the  model,  the  project  officer  should  record  in  the  project 
folder  all  the  information  considered  by  the  design  team  for  each 
perspective,  during  each  phase.  This  record  can  be  instrumental  in  the 
following  ways: 

1 .  it  can  assist  the  approving  officers  in  understanding  the 
reasoning  behind  the  design  team  decisions; 

2.  it  will  allow  entities  outside  of  the  design  team  to  raise 
concerns,  or  suggest  alternatives,  not  considered  by  the  design 
team; 

3.  it  will  help  replacement  personnel  quickly  visualize  the  project's 
history,  see  where  the  project  stands,  and  comprehend  why  the 
project  has  taken  the  path  it  has. 


12 


Coast  Guard  voice  and  data  telecommunications  requirements  will 
constantly  change  as  technology  evolves  and  mission,  equipment,  and 
software  application  requirements  change.  Therefore,  the 
telecommunications  system  must  also  evolve  to  meet  these  requirements. 
By  following  the  structured  approach  model,  a  migration  plan  to  meet 
these  changing  requirements  will  already  exist;  however,  design  teams 
can  only  forecast  the  future  with  some  inevitable  uncertainly.  As  the 
future  becomes  more  clear,  the  network  manager  may  have  to  request 
adjustments  to  the  migration  plan  to  match  the  actual  environment.  A 
well-documented  migration  plan  provides  an  historical  baseline  the 
network  manager  can  use  to  compare  the  evolving  organization, 
functional  requirements,  and  available  technologies  with  those  forecast 
by  the  design  team.  The  justification  for  requested  changes  will  be 
established  much  more  readily  by  using  a  comparison  to  the  well- 
documented  baseline  than  by  starting  from  scratch.  The  example  in 
Figure  2  illustrates  the  usefulness  of  such  documentation. 
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1996:  Imagine  This... 

In  the  approved  plan,  the  BAGS  design  team  has  chosen  microwave 
as  the  optimal  technology  for  the  Mount  Umunhum  remote  site.  To  back  up 
the  essential  voice  circuits,  in  the  event  of  a  microwave  system  failure,  a 
standby  cellular-based  system  was  chosen  over  a  satellite-based  system  due 
to  estimated  costs  (cellular:  $100/mo.,  satellite:  $150/mo.). 

It  is  now  1999... 

The  cellular-based  system  has  worked  fine,  but  the  actual  costs  have 
averaged  $125/mo.  The  network  manager  does  some  research  and  learns 
that,  with  the  Teledesic  and  Iridium  satellite  systems  operational  since 
1998,  monthly  costs  for  a  satellite-based  system  have  dropped  to  $100/mo. 
and  would  provide  twice  the  data  rate  of  the  cellular  service.  This  would 
allow  the  new  CGXV  data  circuit  to  be  backed  up,  in  addition  to  the  voice 
circuits. 

From  the  BAGS  project  folder,  the  network  manager  has  available  all 
the  considerations  and  estimates  used  by  the  design  team  to  justify  the 
cellular  system.  He  can  readily  make  a  comparison  detailing  the  changes  in 
enviroiunental  factors  to  justify  switching  to  a  satellite-based  system. 


Figure  2:  Elustration  of  Documentation  Effectiveness 


4.  Conclusion 

The  structured  approach  model  assists  the  design  team  by 
providing  a  framework  for  organizing  the  major  phases  of  a  large 
engineering  project.  It  encourages  the  use  of  systems  thinking  by 
providing  a  method  to  document  project  decisions  and  the  reasoning 
behind  them.  The  documentation  will  help  those  outside  the  decision 
process  to  quickly  comprehend  the  project  histoiy  and  the  justification 
used  for  the  path  taken. 
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III.  STRUCTURED  APPROACH  PROCESS: 


PHASES  I  &  II 


A.  INTRODUCTION 

The  structured  approach  model  can  be  used  at  a  variety  of 
strategic  and  planning  levels.  This  chapter  will  briefly  discuss  the  Coast 
Guard  enterprise-wide  level,  then  outline  the  phases  at  a  project 
officer/ design  team  level.  Although  they  will  normally  consist  of  two 
separate  groups,  in  this  paper  the  terms  “design  team”  and  “Architecture 
Work  Group  (AWG)”  will  be  used  interchangeably. 

B.  ENTERPRISE-WIDE  STRATEGY 

Any  project  considered  by  the  MLC  or  HQ  unit  “t”  divisions  should 
correspond,  in  some  manner,  to  the  strategy  outlined  in  the  objectives, 
strategies,  and  goals  established  by  the  Commandant  (this  includes  the 
program  offices).  In  the  Office  of  Command,  Control,  85  Communications 
(G-T),  strategy  is  established  by  the  Board  of  Directors. 

Phases  I  85 II  are  the  strategic  and  system  planning  phases.  Phase 
I  should  be  completed  at  the  Headquarters  level,  using  the  corporate 
objectives  and  vision,  to  build  a  framework  for  the  Coast  Guard’s  overall 
IT  architecture.  Unfortunately,  the  Coast  Guard  does  not  have  a  well- 
defined  process  to  gather  the  IT  requirements  of  the  twelve  Coast  Guard 
programs  (Acquisition(A),  Engineering  85  Development{E),  etc.)  into  an 
integrated  architecture.  At  this  time.  Headquarters  also  lacks  the 
coordination  to  promulgate  a  set  of  standards  that  can  accommodate  the 
various  program  requirements.  Although  not  currently  incorporated  by 
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HQ,  the  Strategic  Approach  Model  could  be  of  great  benefit;  they  could 
use  it  to  outline: 

1.  the  missions  and  goals  of  each  HQ  office  (organizational  view); 

2.  the  functional  requirements  necessary  to  meet  those  goals; 

3.  the  work  processes  necesseny  to  meet  the  functional 
requirements; 

4.  the  high-level  standards  for  applications,  data  definitions, 
information  platforms,  and  a  telecommunications  infrastructure 
that  will  lead  us  in  the  direction  of  an  integrated  target 
architecture; 

5.  a  migration  plan  to  combine  stovepipe  IT  systems  supported  by 
individual  programs  into  an  integrated  Coast  Guard  IT  system 
serving  all  program  requirements. 

The  Maintenance  &  Logistic  Center’s  Command,  Control,  & 
Communications  Budget  85  Planning  Division,  MLC(tb),  should  use  this 
high-level  framework  to  define  the  problem(s)  the  project  will  confront 
and  justify  the  direction  the  project  will  take.  This  could  include,  but  not 
be  limited  to: 

1 .  combining  requirements  of  various  entities  into  larger  projects; 

2.  ranking  projects  to  meet  priorities  as  outlined  by  HQ’s  strategic 
business  plan; 

3.  the  designing  and  implementation  of  projects  to  enable  Coast 
Guard  entities  to  meet  the  strategic  objectives,  as  set  forth  by 
HQ. 

In  the  event  that  the  strategic  business  plan  is  not  outlined  by 
their  superiors,  the  project  officer  must  react  proactively.  Through 
personal  inquiries,  the  project  officer  should  attempt  to  ascertain 
whether  the  project  can  incorporate  unlisted  CG  objectives,  in  addition  to 
the  objectives  listed  in  the  planning  proposal.  No  project  stands  alone; 
its  location  within  the  Coast  Guard  C3  infrastructure  must  also  be 
accounted  for  in  this  phase  [Ref.  13,  p.  22]. 
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C.  PHASE  I  FOR  THE  PROJECT  OFFICER 

The  first  phase  in  the  Structured  Approach  Process  is  the 
“Organizing  and  Planning”  phase.  The  purpose  of  this  phase  is  to 
develop  an  initial  plan  for  the  process  of  engineering  and  managing  a 
system  over  time.  This  phase  in  the  systems  engineering  and 
management  process  lays  the  groundwork  for  the  planning  and  actions 
that  occur  throughout  the  Structured  Approach  Process.  [Ref.  8,  Ch.  6, 
and  Appendix  I] 

This  phase  will  set  the  direction  for  the  rest  of  the  project  to  follow. 
The  final  products  from  this  phase  include: 

1 .  initial  Executive  Guidance; 

2.  the  PURPOSE  of  the  system-in-focus; 

3.  a  VISION  for  the  desired  system  end-state  that  accomplishes 
the  PURPOSE; 

4.  an  initial  PLAN  for  achieving  the  VISION; 

5.  initial  Executive  Approval  and  Support.  [Ref.  9,  p.  M3-6] 

1.  Organizational  View 

Some  of  the  high-level  Mission /Vision  strategic  drivers  for  the 
BAGS  begin  with  the  Commandant’s  Direction[Ref.  10];  in  particular. 
Goal  #8  states,  “Pursue  and  exploit  new  technologies  to  achieve  gains  in 
productivity  and  enhance  mission  performance.”  The  objectives  outlined 
to  meet  this  goal  include: 

1.  redirect  efforts  in  Research  and  Development  to  further  mission 
productivity; 

2.  use  technology  to  enhance  maritime  safety,  surveillance  and 
environmental  systems; 

3.  be  a  partner  with  DOT’s  R85D  efforts  to  develop  integrated  smart 
transportation  and  navigation  information  systems; 

4.  manage  Coast  Guard  information  resources. 
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Each  Coast  Guard  program  that  inputs  or  uses  data  (or  communications) 
carried  on  the  BAGS  will  have  requirements  which  must  be  considered 
when  developing  an  infrastructure  system  such  as  BAGS.  The  timeframe 
for  meeting  the  goals  set  by  the  Mission/ Vision  strategic  drivers  must 
also  be  derived. 

2.  The  Enterprise  Tasks  and  Missions 

The  goals  of  an  enterprise  are  performance-based.  In  other  words, 
“how  do  we  want  to  perform  our  tasks,  and  the  missions  that  drive  those 
tasks.”  This  can  be  seen  in  the  wording  of  the  Commandant’s  goals; 
these  words  include,  “redirect,”  “use,”  “be,”  and  "manage.” 

Headquarters  sets  the  Coast  Guard-wide  goals,  but  Congress 
assigns  us  our  missions.  The  Coast  Guard's  response  to  numerous 
mission  requirements  can  be  modeled  as  a  recursive  process  involving 
the  Coast  Guard  and  Congress.  The  impact  trickles  down  to  BAGS. 

Figure  3  illustrates  the  relationship  between  the  mission-driven 
organizational  architecture,  the  generation  of  new  missions,  and  the 
requests  for  resources  to  meet  the  new  responsibilities. 

The  Coast  Guard's  San  Francisco  Bay  area  enterprise  reflects  the 
results  of  an  evolutionary  layering-on  of  missions.  These  missions  are 
correspondingly  reflected  in  the  functionality  of  the  BAGS.  The  Coast 
Guard  has  adopted  the  policy  that  the  small  size  of  the  service  dictates 
that  these  missions  be  executed  by  small,  multi-mission  units.  Each 
unit  carries  out  multiple  tasks,  simultaneously  or  nearly  simultaneously, 
on  behalf  of  separate  managers  of  the  various  program  areas.  BAGS 
supports  a  similarly  broad  subset  of  all  Coast  Guard  missions.  The 
external  Coast  Guard  missions  BAGS  routinely  supports  can  be  classified 
in  the  following  categories: 

1.  Waterways  Management  seeks  to  develop,  implement,  and 
manage  vessel  traffic  movements  in  congested  or  high-risk  U.S. 
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waters.  Implicit  in  this  definition  is  the  U.S.  declared  limit  of 
three  nautical  miles  for  its  territorial  sea.  The  three  nautical 
mile  limit  bounds  the  system  in  focus  from  a  strictly 
constructed  legal  perspective.  However,  as  a  matter  of 
practicality,  customs  laws  and  the  military  concept  of  a 
commander's  understanding  of  the  relationship  between  time 
and  space  conspire  to  extend  this  bound  to  the  inshore  horizon. 
The  waterways  management  area  of  operations  is  analogous  to 
the  concept  of  battlespace  developed  in  the  Marine  Corps' 
“Command  and  Control,  FMFM  3.” 

Authority  is  exercised  in  the  waterways  management 
mission  through  promulgation  of  federal  regulations  which  are 
either  short-lived  locally-generated  regulations  or  standing 
federal  regulations.  Personnel  and  a  network  of  sensor 
equipment  also  form  the  Vessel  Traffic  System  (VTS).  The  VTS 
continuously  monitors  certain  vessel  movements,  with  the  aim 
of  preventing  collisions  between  participating  vessels. 

2.  Recreational  Boating  Safety  aims  to  reduce  the  risk  of  injury, 
loss  of  life,  and  property  damage  associated  with  the  use  of 
pleasure  craft  in  U.S.  waters.  In  addition  to  numerous  other 
administrative  components  of  the  program,  the  BACS- 
applicable  portion  concerns  command  and  control  functions 
exercised  over  the  volunteers  of  the  Coast  Guard  Auxiliary. 

These  auxiliarists  volunteer  their  time  and  facilities  to 
conduct  intermittent  search  and  rescue  patrols.  When  engaged 
in  those  activities,  their  boats  and  aircraft  require  a 
commensurate  level  of  command  and  control,  flight-following, 
and  communications  resources.  The  requirements  are  met  by 
Group  San  Francisco,  or  a  subordinate  unit,  using  the 
communications  capabilities  inherent  in  BAGS. 
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WWM  -  Waterways  Management 

RBS  -  Recreational  Boating  Safety 

MLE  “  Maritime  Law  Enforcement 

SAR  -  Search  and 

ATON  -  Aids  to  Navigation 

MEP  -  Marine  Environmental  Protection 


Figure  3:  BAGS/ Missions/ Resources  Rlustration 


3.  Maritime  Law  Enforcement  concerns  itself  with  enforcing  all 
applicable  federal  laws  through  inspections,  interdiction,  and 
searches.  The  interdiction  mission  is  supported  by  a  large 
resource-intensive  operational  effort,  and  an  all-source 
intelligence  effort.  Both  these  elements  are  major  requirements 
drivers  for  BAGS. 

The  law  enforcement  "battle  space"  extends  globally  in  the 
intelligence  collection  and  reporting  mission,  and  operationally 
with  regard  to  jurisdiction  over  U.S.  flagged  vessels. 

The  law  enforcement  mission  is  also  characterized  by  a 
requirement  for  a  high  degree  of  interoperability  with  other 
agencies  and  military  forces.  Since  the  late  1980s’  several  DOD 
Joint  Task  Forces  have  been  continuously  expending  resources 
in  counter-narcotics  interdiction  operations  with  the  Coast 
Guard,  adding  their  interoperability  requirements  to  those  of 
the  many  federal  law  enforcement  agencies. 

4.  Search  and  Rescue  includes  the  planning  and  execution  of 
resource-intensive  missions  to  locate  and  recover  people  and 
property  at  sea  and  along  the  shore.  Some  of  the  associated 
information  systems  supporting  the  search  and  rescue  mission 
are  at  the  highest  end  of  the  Coast  Guard's  range  of  information 
systems  complexity.  For  example,  the  Coast  Guard  Data 
Network  component  of  BAGS  supports  a  mainframe-based 
simulation  software  product  which  predicts  wind  and  current- 
induced  drift  that  a  shipwrecked  survivor  or  disabled  vessel  will 
experience  at  sea.  This  in  turn  permits  the  allocation  of 
resource  effort  to  search  in  the  areas  of  highest  probability  of 
detection.  BAGS  is  again  called  upon  to  disseminate  the  results 
of  the  search  planning. 

5.  Aids  to  Navigation  is  a  mission  composed  of  several  distinct 
elements.  Short-range  aids  include  lighthouses,  floating  buoys, 
and  fixed  structures  located  on  or  near  the  water.  Some  of 
these  devices  are  monitored  via  an  electronic  Automated 
Control  and  Monitoring  System  (AMSC).  BAGS  supports  the 
mission  by  transporting  status  reports  on  the  associated  lights, 
signaling  devices,  and  electric  generators. 

Long-range  aids  to  navigation  are  based  on  several 
different  forms  of  radio-navigation.  The  Coast  Guard  also 
publishes  voice  and  textual  reports  informing  mariners  of 
hazards  and  other  safety  and  marine  navigation  issues  for 
waters  in  and  near  the  United  States.  BAGS  supports  the 
dissemination  of  this  information  and  the  management  of  the 
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entire  program,  and  facilitates  the  collection  of  a  useful  series  of 
performance  metrics. 

6.  Marine  Environmental  Protection  exists  to  both  prevent  and 
minimize  damage  to  the  ecological  and  economic  systems  of 
U.S.  ports,  waterways,  and  coastal  areas  caused  by  pollution. 
The  mission  involves  searching  for  and  reporting  oil  spills,  the 
management  of  cleanup  operations,  and  the  dispersing  of  vast 
sums  of  money  for  cleanup  operations.  These  responsibilities 
are  carried  out  by  the  Captain  of  the  Port  through  the  personnel 
of  the  Marine  Safety  Offices  and  Marine  Safety  Detachments. 

3.  Functional  View 

The  next  question  is,  “what  functional  requirements  are  necessary 
to  meet  the  strategic  drivers.”  These  will  include  requirements  such  as: 

1 .  reliability  requirements; 

2.  security  requirements; 

3.  types  and  sizes  of  signals  to  be  carried; 

4.  signal  timeliness  (delay). 

To  “manage  Coast  Guard  information  resources,”  the  requirements 
should  include  minimizing  maintenance  and  network  manager 
requirements.  Therefore,  any  new  system  should  include  self-monitoring 
and  diagnosing  capabilities  to  a  certain  component  level.  To  minimize 
network  management,  automatic  re-routing  (upon  system  failure)  and 
automatic  re-initialization  (upon  system  repair)  should  be  required. 

4.  Physical  View 

We  must  now  address  any  high-level  issues  that  will  affect  the 
telecommunications  architecture.  These  issues  will  include  any 
promulgated  standards  for  telecommunications  systems  and  any  existing 
policies  or  instructions  that  could  affect  the  project  design.  The  issues  of 
environment  and  technology  availability  must  also  be  considered. 
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D.  PHASE  II  FOR  THE  PROJECT  OFFICER 

Phase  II  in  the  Structured  Approach  Process  is  the  “Define  System 
Problem”  phase.  The  purpose  of  this  phase  is  to  structure  the  system 
problem  so  that  all  subsequent  engineering  and  management  efforts  will 
be  both  effective  {doing  the  right  thing)  and  efficient  {doing  things  right). 
This  phase  in  the  systems  engineering  and  management  process  bounds 
the  problem  and  enables  systems  engineers  and  managers  to  focus  on 
the  most  important  issues  and  problems.... [Ref.  1 1,  p.  M3B-1].  The  basic 
product  of  this  phase  should  include  the  Tentative  Operational 
Requirement  (TOR)  paper. 

1.  Organizational  View 

Using  the  organizational  view,  we  need  to  answer  the  question, 
“Organizationally,  what  cannot  occur  without  the  telecommunications 
project?”  These  deficiencies  can  be  developed  by  comparing  the  strategic 
drivers  to  the  capabilities  of  the  existing  system.  Some  of  the  possible 
strategic  drivers  could  include,  but  are  not  limited  to,  the  following: 

1 .  relocation,  or  reallocation  of  resources; 

2.  joint  operations  with  other  units  and/or  organizations; 

3.  change  in  mission  or  role; 

4.  efficient  use  of  Coast  Guard  resources. 

There  were  two  initial  strategic  drivers  for  the  BAGS  project.  One 
was  the  goal  to  standardize  the  equipment  suite  used  by  VTS  San 
Francisco  with  the  equipment  suites  being  installed  at  VTS  New  York  and 
VTS  Puget  Sound.  The  other  strategic  driver  originated  in  Congress.  The 
goal  was  to  free  up  a  portion  of  the  government  controlled  frequency 
spectrum  for  civilian  use. 
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There  are  other  existing  strategic  drivers,  however,  that  must  be 
researched  before  all  the  functional  requirements  can  be  addressed. 
Some  of  these  strategic  drivers  are  being  brought  on  by  the  Coast  Guard 
streamlining  effort.  In  particular,  these  drivers  include  the  following: 

1 .  the  merging  Eleventh  District  with  Pacific  Area; 

2.  the  transfer  of  support  functions  from  district  offices  to  the 
MLC’s; 

3.  the  inception  of  Activity  Commands  effecting  the  command  and 
control  structure  of  groups.  Marine  Safety  Offices  (MSO’s),  air 
stations,  and  VTS’s.  [Ref.  12] 

Again,  it  is  imperative  we  know  where  we  are  going,  if  we  are  to  perform 
effectively  and  efficiently. 

2.  Functional  View 

Using  the  functional  view,  we  need  to  answer  the  question,  “What 
HQ  or  emit  functional  requirements  cannot  be  met  without  the  project?” 
These  requirements  are  extrapolated  from  the  strategic  drivers;  however, 
they  will  usually  come  in  the  form  of  requests  from  units,  or  programs,  to 
change  or  upgrade  functional  capabilities.  It  is  important  to  justify  the 
changes  in  functional  requirements  to  their  strategic  drivers.  Project 
proposals  which  support  G-T  goals  generally  get  high  priority  for 
approval  and  resources  [Ref.  13,  p.  21].  This  statement  could  also 
include  Area  and  Program  managers  goals,  depending  on  the  source, 
control  and  availability  of  resources. 

Some  of  the  BAGS  functional  requirements  that  cannot  be  met  by 
the  existing  system  include,  but  are  not  limited  to,  the  following: 

1.  the  ability  to  transfer  digital  data  from  remote  sites  to  VTC  San 
Francisco; 

2.  the  implementation  of  new  digitally-controlled  equipment, 
including  VHF  radios,  direction  finders,  and  radar  processors; 
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3.  rerouting  of  signals,  in  the  event  of  a  link  failure,  within  the 
telecommunications  system. 

3.  Physical  View 

Using  the  physical  view,  we  need  to  answer  the  question,  “Is  there 
anything  from  the  physical  view  that  is  causing  the  project?”  These 
could  include  equipment  issues  (e.g.,  lack  of  replacement  parts, 
reliability,  etc.)  or  maintenance  issues  (e.g.,  high  maintenance  costs,  lack 
of  trained  maintenance  personnel,  etc.).  In  the  BAGS  case,  the 
equipment  cannot  meet  the  new  functional  requirements  (i.e.,  operating 
outside  the  2  GHz  frequency  spectrum).  The  equipment  also  has  high 
maintenance  costs  and  lack  of  manufacturer  support  for  replacement 
parts. 

E.  THE  TENTATIVE  OPERATIONAL  REQUIREMENT  (TOR) 

The  TOR  is  the  initial  phase  in  the  formal  requirements  validation 
process  and  is  usually  submitted  by  the  support/ operating  program 
manager  when  there  is  a  perceived  need  for  a  new  operational  capability. 
The  contents  for  a  TOR  are  listed  in  Figure  4.  The  TOR  is  analyzed  by  G- 
T  (or  MLCt)  branch  personnel  to  verify  the  requirement,  determine  if  a 
Development  Options  Paper  (DOP)  is  required,  and  provide  alternative 
solutions.  The  project  officer  may  have  to  assist  the  program  manager 
(or  requesting  command)  in  writing  the  TOR.  This  is  an  advantage 
because  it  gives  the  AWG  an  early  opportunity  to  help  identify  the  real 
needs.  If  the  formal  process  is  not  being  used  —which  is  likely— then  the 
project  officer  should  develop  a  “straw”  TOR  using  the  same  format. 

When  the  straw  TOR  is  submitted  to  the  branch  chief,  it  will  demonstrate 
that  the  project  officer  has  done  the  homework  necessary  to  identify  the 
true  issues.  [Ref.  13,  p.  23] 


25 


The  TOR  summarizes  all  tlie  end  products  of  phases  I  and  II. 

Using  the  executive  guidance  provided,  the  design  team  will  have 
explained  the  purpose  of  the  system.  By  developing  the  high-level 
functional  requirements,  the  AWG  can  envision  the  desired  end-state 
system  and  outline  an  initial  plan  for  achieving  this  vision.  The  problem 
has  been  bound  by  using  the  organizational,  functional,  and  physical 
views. 
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FORMAT  FOR  TENTATIVE  OPERATIONAL  REQUIREMENT  fTORl 
(3-page  limit,  excluding  cover  sheet) 

I.  Cover  Sheet.  Serves  in  lieu  of  forwarding  letter. 

n.  Subiect/Title.  Provide  a  short  one  line  subject/title. 

III.  General  Description  of  Operational  Requirement.  Describe  the  type  of 
system  needed  and  its  general  concept  of  operations. 

IV.  Threat.  The  threat  section  should  either  address  the  threat  the  system  is 
being  designed  to  counter,  the  threat  environment  in  which  the  system 
must  operate,  or  the  threat  to  the  environment  that  must  be  resolved. 

V.  Deficiencies /Shortcoming  of  Existing  Systems.  At  a  mim'Trmm  classify  the 
deficiency  as  one  of  the  following: 

A.  Operational  Deficiency  -  inhibits  the  performance  of  a  mission  or  the 
execution  of  operational  plans. 

B.  Characteristic  Deficiency  -  inhibits  the  performance  of  mission  in 
accordance  with  doctrinally  prescribed  characteristics  (connectivity, 
security,  speed,  reliability,  interoperability.. .etc.) 

C.  Conceptual  Deficiency  -  deficiency,  when  corrected  can  materially 
improve  operations  by  providing  new  capabilities;  solutions  will 
require  significant  development. 

VI.  Range  of  Capabilities  Desired.  Outline,  in  general  terms,  the  key 
capabilities  desired.  Include  capabilities  required  versus  adverse  ocean 
environment  sensitivities.  Allow  broadest  possible  range  of  acceptable 
performance  levels  from  modest  improvement  of  existing  systems  to  major 
advances. 

VII.  General  Affordability  limits.  Provide  an  estimate  (round  numbers)  of  what 
the  resource  sponsor  is  willing  to  pay  (in  constant  dollars,  using  current 
year  dollars  for:  a)  RDT&E;  b)  average  unit  costs;  and  c)  life-cycle  cost 
(RDT&E,  procurement,  installation,  and  five  years  of  operation,  all 
appropriations).  This  affordability  limit  serves  as  a  constraint,  rather  than 
a  fixed  limit,  for  preparing  the  DOP. 

VIII.  Facilities  /  Platform  /  Quantities.  Identify  facilities/ ships/ aircraft,  etc.  which 
will  employ  the  system  (if  applicable),  and  estimate  number  to  be  procured. 

IX.  Integrated  Logistics  Support  flLSl.  Describe  any  required  or  limiting  logistic 
planning  considerations,  including  manpower/ personnel/ training.  Provide 
essential  direction  regarding  the  nature  of  the  program  required  including 
compliance  with  or  exceptions  to  key  policies  and/or  procedures. 

X.  Background /Related  Efforts.  Discuss  interfacing  systems,  companion 
developments,  etc..  Identification  of  foreign  systems  that  can  reasonably 
satisfy  the  range  of  capabilities  specified  shall  be  specifically  requested  in 
the  TOR. 

XI.  Program  Manager.  Clearly  identify  all  program  managers,  who  will  be  the 
end  user  of  the  system.  Also  identify  any  other  program  managers  who  will 
be  affected  by  the  acquisition,  (i.e.,  the  program  managers  of  all  floating 
platforms  or  shore  stations). 

XII.  Acquisition  Strategy.  Summarize  overall  plan  for  contracting  and 
procurement,  including  contract  type  and  incentives. 

Figure  4:  Tentative  Operational  Requirement  (TOR) 
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F.  CONCLUSION 

Phases  I  and  II  are  the  foundation  on  which  any  project  is  founded. 
If  the  project  officer  is  not  aware  of  the  driving  issues  behind  the 
decisions  made  during  these  phases,  the  project  can  quickly  get  off  track. 
The  project  officer  should  not  only  make  a  great  effort  to  understand  the 
driving  issues,  but  should  be  willing,  and  allowed,  to  question  the  issues 
and  decisions  made  during  these  phases.  The  Coast  Guard’s  Command, 
Control,  and  Communications  (“T”)  leadership  must  form  and 
disseminate  a  well-defined  set  of  strategic  objectives  for  the  community. 
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IV.  BASELINE  CHARACTERIZATION 


A.  INTRODUCTION 

The  baseline  characterization  is  the  third  process,  or  phase,  in  the 
Structured  Approach  Model.  The  purpose  of  a  baseline  characterization 
is  to  provide  the  design  team  a  better  understanding  of  the  existing 
system.  The  baseline  characterization  must  cover  both  the 
telecommunications  network  and  the  users  systems. 

A  baseline  characterization  of  the  existing  systems  is  a  critical  phase 
in  the  process  of  targeting  and  developing  either  a  follow-on  or  new 
telecommunications  network.  Without  examining  the  current  systems,  it 
is  difficult  to  determine  the  degree  to  which  the  telecommunications 
network  must  be  upgraded  or  replaced.  Determining  the  existing  systems 
objectives,  processes,  and  performance  permits  the  design  team  to  target 
an  architecture  that  best  fits  the  functions  and  objectives  of  the  enterprise. 
The  enterprise  integrates  processes  and  procedures,  both  manual  and 
automated,  for  all  Coast  Guard  mission  areas  and  their  associated 
functions.  In  our  analysis,  the  “enterprise”  is  comprised  of  U.S.  Coast 
Guard  units  in  the  San  Francisco  Bay  Area  that  use  the  BAGS. 

To  better  understand  the  system,  the  design  team  will  use  the 

baseline  characterization  to  generate  a  high-level  description  of  the 
physical  aspects  of  the  user  systems  and  existing  telecommunications 
network.  The  design  team  will  take  the  mission  goals  and  high-level 
functional  requirements  gathered  when  we  “defined  the  problem,”  and 
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break  them  down  into  more  detailed  requirements.  These  requirements, 
in  turn,  will  be  broken  into  actual  work  processes  and  tasks  which  must 
be  completed  to  meet  the  requirements.  Again,  we  will  use  the  functional, 
the  physical,  and  the  organizational  perspectives  to  accomplish  this. 

B.  ORGANIZATIONAL  VIEW 

The  organizational  viewpoint  is  concerned  with  the  actual  working 
processes  used  by  the  enterprise  to  meet  its  functional  goals.  These 
include  working  processes  which  are  performed  by  personnel  or  by 
equipment.  For  example,  a  functional  requirement  may  state,  “Group 
duty  watchstanders  shall  transmit  marine  safety  notices  every  four  hours 
simultaneously  over  the  group  area  of  responsibility  (AOR).”  This 
requirement  would  include  working  processes  performed  by  the 
watchstander  (prepare  Notice  to  Mariners,  manually  press  switch,  and 
speak)  and  those  performed  automatically  by  the  equipment  and 
software  to  enable  the  signal  to  transmit  over  numerous  VHF-FM  radios 
concurrently. 

When  completing  a  baseline  characterization  on  a  complete 
information  system,  all  work  processes  performed  by  the  enterprise 
should  be  considered.  As  engineers,  we  must  understand  the  work 
processes  if  we  are  to  design  the  new  information  system  to  be  both 
effective  and  efficient.  Some  work  processes  are  effective,  but  are  not 
efficient.  Prior  to  a  telecommunications  replacement  project  is  the 
perfect  time  for  the  Coast  Guard  enterprise  to  consider  re-engineering 
inefficient  work  processes.  Normally,  however,  the  telecommunications 
network  design  team  will  have  very  limited  resources.  Therefore,  the 
scope  of  this  paper  is  limited  to  those  work  processes  directly  related  to 
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the  telecommunications  network  and  the  system  applications  that 
interface  through  the  network. 

1.  Determine  the  Organizational  Structure 

The  definition  of  organizational  structure  used  here  is,  “The 
structure  which  controls  the  flow  of  the  work  processes.”  This  entails 
two  aspects  the  design  team  must  keep  in  mind:  1)  the  sequential 
procedures  which  must  be  performed  to  complete  the  process,  and  2)  the 
physical  location  of  resources  used  to  perform  the  processes.  For  a 
simple  illustration  of  how  important  these  two  aspects  are  to 
understanding  the  system,  we  will  take  another  look  at  the  watchstander 
example.  The  sequential  procedures  include  switching  the  console 
controls  to  an  “all  broadcast”  position,  which  in  turn  initiates  software 
that  sends  a  control  signal  simultaneously  over  the  telecommunications 
network  to  all  VHF-FM  remote  sites.  This  signal  switches  the  radios  to 
the  transmit  position.  However,  the  design  team  must  be  aware  of  the 
locations  of  the  VHF-FM  radios  if  they  are  going  to  design  a 
telecommunications  network  to  pass  these  signals.  This  example  shows 
where  the  organizational  and  physical  views  converge. 

C.  Functional  View 

The  functional  view  addresses  the  fundamental  issue  of  what  Hie 
system  enables  the  enterprise  to  accomplish.  This  has  two  aspects.  The 
design  team  must  consider  1)  each  unit’s  functionality  and  2)  the  role  the 
existing  telecommunications  system  plays  in  achieving  the  unit’s 
elemental  missions.  The  functional  viewpoint's  relationships  to  the 
physical  and  organizational  viewpoints  must  also  be  considered. 

On  a  superficial  level,  the  BAGS  provides  simple  connectivity 
among  the  entities  comprising  the  Coast  Guard  in  the  Bay  Area. 
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However,  a  more  careful  analysis  reveals  that  the  BAGS  provides  the 
enterprise  with  a  wide  variety  of  functionality.  These  functions  can  be 
categorized  as  both  mission  area  functions  and  support  functions. 

Many  of  the  mission  area  functions  derive  directly  from  the 
legislated  responsibilities  of  the  Coast  Guard.  These  mission  area 
applications  are  those  which  directly  interact  with  the  Coast  Guard's 
external  customers.  These  interactions  are  manifested  in  artifacts  such 
as  marine  safety  information,  operational  unit  employment  metrics. 
Broadcast  Notices  to  Mariners,  distress  messages,  and  Urgent  Marine 
Information  Broadcasts. 

However,  in  this  context,  mission  area  functions  additionally 
include  those  applications  required  to  implement  all  specific  end-user 
requirements,  e.g.,  personnel  management  information  for  internal 
Coast  Guard  use. 

BAGS'  support  functions  include  those  common  applications  which 
are  standardized  across  the  various  mission  areas.  These  underl5dng 
services  are  available  to  several  mission  area  functions  as  needed.  In  a 
distributed  architecture,  these  applications  would  provide  such  services 
as  electronic  mail,  text  editing,  and  spreadsheet  functionality.  They 
would  serve  as  building  blocks  which  could  be  called  by  other 
applications,  remotely,  to  contribute  to  their  own  functionality. 

In  the  BAGS  case,  the  services  and  functionality  provided  by  each 
layer  of  the  ISO/OSI  7  layer  model  of  telecommunications  provides  a 
similar  imderlying  suite  of  support  applications.  For  example,  the 
transport  layer  provides  error  and  flow  control  services  across  the 
network  to  the  session  layer  above  it. 

In  large  measure,  the  functions  the  BAGS  performs  in  support  of 
the  Goast  Guard  are  derived  from  the  missions  assigned  to  the  Goast 
Guard  itself  by  the  U.S.  Gongress.  Systems  designed  to  meet  functional 
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objectives  can  have  other,  dramatic  effects.  The  virtual  organizational 
reengineering  that  a  networking  infrastructure  such  as  BAGS  can 
implement  could  help  initiate  and  expand  a  horizontal  integration. 

1.  Functional  Requirements  of  the  Enterprise 

a.  Determine  the  Users’  Functional  Requirements 

Each  unit  has  their  own  mission  requirements,  and  therefore 
their  own  functional  requirements.  These  requirements  are  the  basis  for 
the  system  specification. 

Gathering  and  documenting  functional  requirements  is  a 
collaborative  effort.  The  project  officer  must  work  with  the  users,  and 
other  CG  entities,  to  fully  document  these  requirements.  These  include 
mission  sponsors  (HQ  program  offices),  support  facilities,  users  within 
each  unit  division  and  chain  of  command.  This  collaboration  will  ensure 
all  the  functional  requirements  are  documented  and  ensure  functional 
requirements  have  not  been  misconstrued  between  the  different  entities 
involved.  Everyone  must  be  working  from  the  same  sheet  of  music,  so  to 
speak. 

b.  Rank  User  Requirements 

The  level  to  which  every  mission  is  fulfilled  must  be  limited. 
Limiting  the  mission  also  limits  the  functionality  required.  The  limiting 
factor(s)  can  be  cost,  technology,  time,  law,  or  any  number  of  other 
factors.  Normally,  the  functional  requirements  necessary  to  complete  the 
mission  are  not  spelled  out  in  black  and  white.  Every  entity  involved  with 
the  mission  (i.e.,  mission  sponsor,  district,  unit  commander)  may  have  a 
differing  view  on  what  level  of  functionality  is  necessary. 

For  instance,  the  mission  for  the  Vessel  Traffic  Service  (VTS) 
is  to  foster  safe  travel  for  vessels  of  a  certain  size  or  type  through  San 
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Franciscan  waters,  as  designated  by  Congress.  One  level  of  functionality 
would  be  to  prevent  collisions  between  participating  vessels.  Other  levels 
of  functional  could  include  preventing  collisions  between  participating 
vessels  and  pleasure  boats,  or  between  participating  vessels  and  floating 
logs.  These  three  different  levels  of  functionality  require  different  levels 
of  technical  capability.  The  VTS  would  like  to  prevent  collisions  between 
ALL  participating  vessels  and  pleasure  boats  and  floating  logs.  This  is 
great  for  customer  satisfaction,  as  well  as  job  satisfaction.  However,  the 
mission  sponsor,  in  this  case  (G-N),  must  be  willing  to  foot  the  bill  for  the 
additional  technical  capability  necessary  to  provide  the  desired  level  of 
functionality. 

What  must  be  considered  is  the  incremental  differences 
between  meeting  the  different  levels  of  functionality  and  whether  the  unit 
(or  sponsor)  is  willing  to  pay  those  incremental  costs.  The  three  different 
mission  requirements  mentioned  above  could  be  categorized  as  follows: 

•  CATEGORY  1 :  “must  have”  -  the  functionality  required  to  prevent 
collisions  between  participating  vessels.  This  is  the  functionality 
which  all  agree  is  necessary  for  mission  success. 

•  CATEGORY  2:  “should  have”  -  the  functionality  required  to 
prevent  collisions  between  participating  vessels  and  pleasure 
boats.  This  is  the  functionality  which  many  feel  is  necessary  for 
political  or  PR  reasons. 

•  CATEGORY  3:  “nice  to  have”  -  the  functionality  required  to 
prevent  collisions  between  participating  vessels  and  floating  logs. 
This  is  the  functionality  which  would  make  the  mission  much 
easier  or  satisfying,  or  add  to  the  public’s  view  of  the  Coast  Guard. 
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Once  a  unit’s  functional  requirements  have  been  noted,  each 
functional  requirement  should  be  placed  into  one  of  the  three  categories. 
This  will  help  us  during  the  upcoming  phases  of  the  structured  approach 
model. 


2.  Matching  Functionality  to  the  Information  Systems 

At  another  level  of  abstraction,  however,  we  can  focus  on  the 
specific  functions  the  BAGS  system  provides  in  achieving  the  unit’s 
elemental  missions.  This  functionality  is  provided  through  ten  coherent 
systems.  Each  is  used  to  gather  or  disseminate  information;  therefore, 
we  shall  refer  to  them  as  information  systems.  These  ten  independent 
information  systems  can  be  drawn  upon  by  the  enterprise  in  many 
varying  combinations  of  functionality. 

The  information  systems  that  operate  over  BAGS  to  provide 
enterprise  functionality  are  outlined  in  the  following  ten  subsections. 
Table  1,  starting  on  page  41,  contains  an  inventory  of  the  information 
systems  available  at  each  existing  site. 

a.  Coast  Guard  Data  Network  (CGDN) 

(1)  Description 

GGDN  is  the  Goast  Guard's  INTERNET,  with  access  at 
all  stations  within  the  BAGS.  Each  location  has  a  computer  terminal 
which  is  linked  via  microwave  to  either  Goast  Guard  Island  or  Group  San 
Francisco.  These  two  sites  are  linked  directly  into  the  GONUS-wide 
WAN,  enabling  direct  contact  with  all  other  GG  entities.  A  functional 
block  diagram  for  the  GGDN  can  be  found  in  Appendix  B  on  page  150. 

(2)  Functions 

1 .  Electronic  mail; 

2.  Record  message  traffic  (naval  messages); 
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3.  Marine  Safety  Information  System  updates; 

4.  Search  and  Rescue  Management  Information  System  updates; 

5.  Law  Enforcement  Information  System  updates; 

6.  Large  Unit  Financial  System  updates. 

b.  VHF-FM  (Voice)  for  Vessel  TrafTtc  System  (VTS)  & 

National  Distress  System  (NDS) 

(1)  VTS  VHF  Description 

VTS  is  a  VHF-FM  radio  system  linked  on  land  by 
microwave,  with  transmit/ receive  sites  located  along  the  coast.  A 
functional  block  diagram  for  the  VTS  can  be  found  in  Appendix  B  on 
page  151. 

(2)  VTS  VHF  Functions 

VTS  is  a  system  used  by  Masters,  Pilots,  and 
Commanding  Officers  piloting  commercial  and  government  vessels  in  the 
waters  subject  to  the  jurisdiction  of  the  Vessel  Traffic  Scheme  (areas  in 
and  around  San  Francisco  Bay). 

(3)  NDS  VHF  Description 

NDS  is  a  system  similar  to  the  VTS  but  broader  in 
scope,  with  coverage  from  areas  north  of  San  Francisco  (around  Bodega 
Bay)  to  south  of  Monterey.  While  Figure  5  contains  a  simple  illustration 
of  the  NDS  functionality. 

(4)  NDS  VHF  Function 

The  system  carries  out  three  completely  separate 

functions: 

1 .  Command  and  control  of  Coast  Guard  cutters,  boats,  and 
aircraft  in  the  coastal  region; 
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2.  Voice  radio  interaction  with  the  public; 

3.  Receipt  of  reports  from  mariners  in  distress. 


Figure  5:  VHF  NDS  Functionality  Rlustration 

c.  Air  Control  UHF  Voice/Data 
(1)  Description 

This  UHF /  Data  System  connects  Air  Station  San 
Francisco  with  Coast  Guard  Island,  and  utilizes  Mt.  Tam  as  a 
transmit/ receive  high  site  for  extended  range  coverage  around  the  San 
Francisco  Bay  Area.  A  functional  block  diagram  for  this  system  can  be 
found  in  Appendix  B  on  page  152. 
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(2)  Function 

The  UHF/Data  System  enables  Air  Station  San 
Francisco  to  exercise  longer  range  command  and  control  and  allows 
Coast  Guard  Island  to  monitor  the  channels. 

d.  High  Speed  Teletype/Data  Network  (/HDN)  and  PACINT 

(1)  Description 

HSTN/HDN  is  the  primary  means  of  teletype  (hard 
copy)  message  communications  for  Bay  Area  Coast  Guard  units.  PACINT 
is  an  intelligence  support  link  between  COMMSTA  San  Francisco  and 
PACAREA  at  Coast  Guard  Island.  A  functional  block  diagram  for  this 
system  can  be  found  in  Appendix  B  on  page  154. 

(2)  Function 

HSTN/HDN  supports  the  PACINT  system  and  all  other 
BACS  telet3^e  users  for  data  dissemination  for  law  enforcement  and 
intelligence  purposes. 

e.  CGI  Phone  (T elephone  PBX  System) 

(1)  Description 

This  system  is  composed  of  microwave  links  between 
various  sites,  telephone  handsets,  and  a  BACS  to  PBX  link  located  at 
Coast  Guard  Island.  A  functional  block  diagram  for  this  system  can  be 
found  in  Appendix  B  on  page  155. 

(2)  Function 

Provides  telephone  service  throughout  the  BACS  area, 
and  provides  a  connection  to  Public  Switched  Telephone  Network  (PSTN) 
and  Federal  Telephone  System  (FTS).  The  system  is  used  as  an  in-house 
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backup  for  civilian  PSTN  and  FTS  and  as  a  maintenance  phone  for 
technicians  working  at  BAGS  microwave  sites. 

f.  Miscellaneous  Systems  (HF  Radio,  Video,  Radar, 

CAMSPAC  Link,  Alarms) 

(1)  Description 

All  of  these  systems  are  composed  of  similar  two-way 
links  from  a  home  site  to  a  remote  site,  with  various  functions  as 
described  below.  A  functional  block  diagram  for  these  systems  can  be 
found  in  Appendix  B  on  page  156. 

(2)  Functions 

The  HF  radio  system  provides  high  frequency  voice 
communications  from  Group  San  Francisco  to  ships  at  sea,  transmitted 
and  received  over  radio  equipment  located  at  Point  Bonita.  Control  sig¬ 
nals  which  operate  the  equipment  are  also  sent  via  microwave. 

CCTV  video  signals  are  transmitted  over  T-1  lines  from 
four  remote  sites  to  the  VTS  center.  The  video  is  used  to  observe  vessel 
traffic  as  part  of  the  VTS.  Camera  control  signals  are  sent  via  T-1  from 
the  center  to  the  individual  cameras  to  select  the  desired  field  of  view. 

Radar  signals  are  transmitted  over  T-1  lines  from  one 
remote  site  at  Point  Bonita  to  the  VTS  center.  The  radar  data  is  used  to 
observe  vessel  traffic  as  part  of  the  VTS.  Radar  control  signals  are  sent 
via  microwave  from  the  center  to  the  radar  antennae. 

CAMSPAC  Link  provides  a  large  number  of  audio, 
data,  and  control  signals,  via  microwave,  between  the  transmitting  and 
receiving  sites  at  the  Communications  Area  Master  Station. 

Alarm  signals  are  transmitted  from  remote  sites,  via 
microwave,  to  a  monitoring  station.  This  system  is  used  in  maintaining 
the  status  of  aids  to  navigation  as  part  of  the  Aids  Control  and 
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Monitoring  System  (AMSC).  Alarm  signals  for  security  and  equipment 
located  at  the  remote  sites  are  also  transmitted  back  to  monitoring 
equipment  on  CG  Island. 
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Table  1:  BAGS  Information  System  Inventory 


Radios  Point  Bonita 

Mount  Tamalpais  Control  Operator  Console 

TV  Hill 


D.  PHYSICAL  VIEW 

The  physical  view  will  outline  the  physical  configuration, 
coordination,  and  resources  required  by  the  existing  system  to  operate 
efficiently  and  effectively.  The  physical  view  will  be  broken  into  three 
sections:  1)  physical  architecture,  2)  physical  sites,  and  3)  maintenance. 
The  relationships  of  the  physical  viewpoint  to  the  organizational  and 
functional  viewpoints  are  also  of  concern. 

1.  Physical  Architecture 

a.  General  Description 

The  Bay  Area  Communications  System  (BAGS)  is  an 
analog  microwave  system  which  operates  in  the  two  gigahertz  (GHz) 
frequency  range.  BAGS  links  at  least  eleven  Coast  Guard  units  to  remote 
sites  using  18  microwave  radio  links.  Each  unit  is  also  linked  to  external 
networks  (e.g.,  PSTN)  through  the  telephone  PBX  system  located  at  the 
communications  system’s  hub  on  Coast  Guard  Island. 

b.  Existing  System  Configuration 

Since  the  entire  analog  microwave  system  will  be  replaced, 
an  in-depth  study  of  the  existing  system’s  physical  configuration  and 
operating  characteristics  is  unnecessary.  However,  a  list  of  major 
components  with  their  descriptions  and  locations  will  be  necessary 
during  the  removal  phase. 

Of  major  concern  are  the  existing  circuit  configurations.  A 
detailed  study  of  each  existing  circuit  must  be  completed.  Information 
gathered  on  each  circuit  should  include  at  least  the  following. 

1.  Bandwidth  required 

2.  Signal  formats/ interoperability  requirements 
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3.  Locations  of  circuit  connections 

4.  Sensitivity  to  data  delays 

5.  Sensitivity  to  disruptions  in  service 

This  is  to  ensure  the  requirements  of  all  existing  circuits  are  considered 
when  choosing  and  designing  the  network  replacement. 

c.  Hardware  Components 

Most  microwave  links  have  a  single  antenna  at  each  end. 
Each  link  end  also  has  a  receiver,  transmitter,  and  "hot  standby" 
transmitter.  This  "hot  standby"  transmitter  automatically  assumes  the 
transmission  responsibilities  when  the  main  transmitter  fails.  Two  of  the 
BAGS  microwave  links  cover  long  distances  over  water.  The  water 
reflects  the  signal,  causing  a  second  signal  to  arrive  at  the  receiving 
antenna  shortly  after  the  intended  signal.  These  signal  reflections  cause 
multipath  reception  problems.  Additional  antennas  and  a  technique 
known  as  space  diversity  are  used  at  each  end  of  these  links  to  overcome 
the  multipath  reception  problems.  This  approach  enables  the  system  to 
function  effectively  despite  the  long  over- water  paths  required. 

2.  Evaluating  the  Existing  System  Baseline 

An  evaluation  of  the  existing  network  must  be  completed.  A  “list  of 
network  deficiencies”  should  be  compiled  and  include  items  such  as 
links  with  high-fade  margin  rates,  and  required  services  not  provided  by 
the  existing  system.  A  “list  of  opportunities”  should  be  collected  and 
include  items  such  as  excess  circuits  and  circuits  that  can  be  combined 
or  deleted  entirely. 

a.  Measures  of  Performance 

Measures  of  performance  (MOP)  can  be  used  to  indicate 
whether  or  not  a  network  meets  the  functional  or  technical  requirements 
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it  was  intended  to  satisfy.  The  Coast  Guard  has  not  been  using  any  MOP 
to  track  the  microwave  network’s  overall  performance.  No  records  of 
network  failure,  calibration,  or  component  replacement  have  been 
generated. 

However,  there  are  four  communications-oriented  measures 
of  performance  used  by  the  Coast  Guard  to  ensure  the  communications 
links  between  sites  remain  within  nominal  specifications: 

1 .  Fade  Margin  -  Measures  signal  attenuation  across  a  microwave 
link 

2.  Receiver  Signal  Level  -  Measures  carrier  signal  power  level 

3.  Baseband  Level  -  Measures  the  incoming  Baseband  signal 
strength 

4.  Idle  Channel  Noise  Level  -  Measures  the  amount  of  noise 
created  by  the  microwave  system  itself. 

Since  any  alternative  supporting  system  would  likely  be 
based  on  a  different  technology,  additional  development  of  MOP  for  the 
existing  network  would  not  be  beneficial. 

3.  Physical  Sites 

a.  Types  of  Sites 

There  are  four  fundamentally  different  types  of  physical 
locations  (sites);  "mega- station"  (Group  San  Francisco  and  Coast  Guard 
Island),  "station,”  "relay  high  site,”  and  "navaid/end  site.”  Their 
descriptions  are  as  follows: 

1 .  The  "mega-station"  category  includes  both  Group  San 
Francisco  and  Coast  Guard  Island,  the  two  primary 
communications  hubs  that  support  the  command  and  control 
structure  for  this  region  of  California.  The  two  sites  contain  all 
or  most  of  the  communications  systems  previously  described 
above  in  Section  B,  Functional  Architecture.  A  drawing 
showing  a  consolidated  version  of  the  two  sites  can  be  found  in 
Appendix  B  on  page  156. 
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2.  A  "station"  includes  sites  such  as  Group  Monterey,  Bodega 
Bay,  and  Air  Station  San  Francisco.  These  sites  are  primarily  at 
the  operational  level,  and  control  specific  missions  within  their 
respective  areas  of  responsibility.  "Station"  sites  either  control 
or  receive  information  from  "navaid/end  sites"  directly  or  via 
"relay  high  sites.”  A  drawing  showing  a  generic  version  of  a 
"station"  can  be  found  in  Appendix  B  on  page  157. 

3.  "Relay  high  sites"  are  located  on  topographically  high 
locations  throughout  the  BAGS  area,  and  provide  the  line-of- 
sight  necessary  for  the  microwave  communication  links,  and 
good  transmit/ receive  locations  for  the  UHF/VHF  radios.  These 
sites  connect  from  two  to  six  microwave  links  together.  A 
drawing  showing  a  generic  version  of  a  "relay  high  site"  can  be 
foimd  in  Appendix  B  on  page  158. 

4.  "Navaid/end  sites"  are  primarily  remote  sensor  (radar, 
television  monitor,  radio  antenna)  or  navaid  sites  (light  house). 
Control  signals  for  these  remote  sites  are  received  via 
microwave  or  T-1  lines,  and  the  sensed  data  is  returned  to  the 
controlling  station  via  similar  means.  A  drawing  showing  a 
generic  version  of  a  "navaid/end  site"  can  be  found  in  Appendix 
B  on  page  159. 
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b.  Site  Configuration 

Each  site  must  be  visited  and  an  evaluation  of  its  physical 
limitations  such  as  space,  power,  “heating,  ventilation,  &  air 
conditioning”  (HVAC),  remoteness,  tower  limits,  etc.,  must  be  completed. 
A  table,  such  as  that  in  Table  2,  can  be  developed  to  assist  the  project 


Table  2:  Site  Configuration  Table 


ASFO 

BYPT 

•  •  • 

YBIS 

Floor  Space 

Avail  (Ft) 

10x4 

10x4 

•  •  • 

6x4 

Blkhd  Space 

Avail  (H  X  W) 

6  X  5  +  2  X  8 

6  X  4  +  3  X  8 

•  •  • 

8x4  +  2x2 

A/C 

Circuitbreakers 

Avail 

3  (20a)  +  1 

(50a) 

3  (20a)  +  1 

(50a) 

•  •  • 

6  (20a)  +  2 

(50a) 

Rack  Space 

Avail  (H  X  W) 

36x27 

48x27 

•  •  • 

72x27 

UPS  Power 

Avail 

Approx.  15a 

Approx.  20a 

•  •  • 

None 

•  •  • 

•  •  # 

«  •  • 

•  •  • 

•  •  • 

Tower  Weight 

Limit 

•  •  • 

officer  in  documenting  the  sites  physical  limitations.  This  table  will  be 
essential  when  selecting  alternative  technologies  and  equipment  for  each 
site. 


c.  Maintenance 

Network  maintenance  is  performed  to  prevent  or  limit  loss  of 
communications,  and  repair  the  network  after  failure.  The  maintenance 
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resources  required  for  the  new  network  will  normally  differ  from  those  of 
the  existing  network.  However,  a  baseline  of  resources  used  to  maintain 
the  existing  network  is  essential  for  planning.  The  project  officer  can  use 
this  baseline  to: 

1.  compute  the  estimated  costs  associated  with  maintaining  the 
existing  network; 

2.  estimate  the  resources  required  for  the  replacement  network; 

3.  estimate  maintenance  costs  for  the  replacement  network; 

4.  plan  changes  to  the  existing  maintenance  structure  (including 
contracts,  billets,  ordering  procedures,  etc.). 

Since  maintenance  resources  used  for  the 
telecommunications  network  may  also  be  used  for  other  purposes,  the 
maintenance  resources  must  be  broken  down  to  a  level  low  enough  to 
make  these  overlapping  uses  apparent. 

CG  telecommunications  networks  can  use  both  CG  and 
contract  resources.  Quarterly  and  annual  preventive  maintenance  is 
performed  by  Coast  Guard  Telephone  Technicians  assigned  to  the 
Telephone  Technician  Shop  on  Coast  Guard  Island.  Preventive 
maintenance  for  BAGS  is  both  costly  and  very  time  consuming. 
Technicians  are  required  to  be  at  both  ends  of  any  analog  microwave  link 
when  the  network  is  being  adjusted.  This  adds  greatly  to  the  amount  of 
travel  time  required.  Unlike  a  digital  network,  an  analog  network  does 
not  remove  noise  at  each  relay  site  by  regenerating  the  original  signal. 
Therefore,  the  network  must  frequently  be  fine-tuned  to  reduce  noise 
interference. 

Emergency  maintenance  is  performed  by  the  Coast  Guard 
technicians  when  a  link  fails.  Although  no  maintenance  records  have 
been  kept,  technicians  indicate  that  approximately  1-2  failures  occurs 


48 


each  year.  The  link  is  normally  restored  within  3-4  hours,  but,  a  link 
has  been  inoperative  for  as  long  as  three  days. 

The  project  officer  must  also  consider  maintenance  to  the 
building  structures  and  surrounding  grounds.  At  times,  this 
maintenance  is  more  difficult  to  arrange  than  network  maintenance. 

d.  Overall  Assessment 

Without  regard  to  the  costs  of  operating  and  maintaining  the 
network,  BAGS  has  satisfied  the  original  requirements  of  a  privately- 
owned  communications  network.  When  evaluating  the  cost  side  of  a 
cost/ effectiveness  assessment,  however,  the  continued  use  of  BAGS  is 
questionable. 

The  network  incurs  explicit  costs  in  a  number  of  areas, 

including: 

1 .  Salaried  maintenance  technicians  continuously  on  call; 

2.  Electric  power  consumption; 

3.  Recurring  hardware  replacement; 

4.  Recurring  preventive  maintenance. 

Implicit  costs  of  the  network  are  more  problematic.  The 
most  significant  of  these  is  caused  by  BAGS  being  firmly  entrenched  in 
an  obsolete  technology:  the  analog  microwave  network  provides  no 
migration  path  to  high  speed  digital  technology.  The  opportunity  costs 
associated  with  the  limitations  of  this  infrastructure  are  severe. 

The  most  immediate  shortcoming  exists  in  the  lack  of 
significant  broadband  digital  connectivity  between  1)  the  Gommander, 
Pacific  Area's  headquarters  in  Alameda,  and  GAMSPAG;  and  2)  the  VTG 
and  remote  radar  sites.  This  shortcoming  immediately  prohibits  the 
implementation  of  the  Goast  Guard’s  goal  to  eliminate  all  dedicated 
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conununications  personnel  at  the  Alameda  Command  Center  and 
headquarters. 

While  a  concrete  capacity  figure  is  not  forthcoming  from  the 
users,  the  existing  technology  clearly  does  not  support  the  present  vision 
of  the  organization. 

Reliance  on  non-secure  command  and  control  links  via  the 
VHF-FM  system  prevents  the  organization  from  achieving  it  is  command 
and  control  requirements  under  it  is  national  defense  tasking. 

Limitations  of  the  existing  network  again  prevent  the  organization  from 
migrating  to  communication  and  encryption  systems  compatible  with  the 
DOD. 

B.  CONCLUSION 

The  baseline  characterization  is  essential  to  understanding  where 
we  are  going  and  how  we  will  get  there.  A  well  documented  baseline 
characterization  can  prevent  the  design  team  from  overlooking  many  of 
the  smaller  details  that  turn  into  major  problems  as  the  project  moves 
forward.  By  using  the  Structured  Approach  Model,  a  project  officer  will 
ensure  all  aspects  of  the  baseline  characterization  have  been  considered. 

Opportunities  for  reengineering  are  clear.  Feasible  target 
architectures  should  be  explored.  A  target  architecture  should  be  chosen 
which  best  matches  the  anticipated  future  requirements,  expected 
technology  maturation,  and  realistic  funding  levels  achievable.  A 
cost/ effectiveness  analysis  must  be  conducted  to  support  the 
procurement  decision.  A  privately  owned  microwave  network  is  only  one 
of  several  possible  alternatives  to  meet  the  future  requirements  presently 
served  by  BAGS. 
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V.  TARGET  ARCHITECTURE 


A.  INTRODUCTION 

“Determine  Target  Architecture”  is  the  fourth  process  of  the 
Structured  Approach  Model.  Recall  that  the  design  team  must  determine 
target  architecture  for  each  of  the  users  systems  before  a  network  target 
architecture  can  be  considered.  The  purpose  of  the  Target  Architecture 
process  is  to  outline  the  technical  capabilities  the  final  network 
configuration  must  possess  to  meet  the  user  requirements. 

The  new  architecture  need  not  be  developed  based  on  cost-effective 
or  “business  case-based”  criteria.  The  real  world  constraints  of 
cost/ effectiveness  analysis  and  cost  justification  will  be  introduced  in  the 
“Select  Migration  Path”  phase  of  the  Structured  Approach  Process. 

At  this  phase  in  the  process,  it  is  desirable  to  define  a  target 
architecture  that  can  be  used  to  achieve  the  vision  of  the  organization 
from  all  three  views.  Ultimately,  constraints  will  come  to  bear  on  the 
funding  of  each  project  that  is  needed  to  achieve  the  target;  but,  for  now, 
it  is  sufficient  to  flesh  out  the  target  to  identify  the  full  spectrum  of  what 
is  needed  to  achieve  the  vision  of  the  organization  [Ref.  ,  p.  4-3]. 

Sometimes  an  organization  cannot  implement  the  target 
architecture  without  either  disrupting  the  quality  of  service  provided  to 
the  enterprise  or  expending  an  excessive  amount  of  resources  to  get 
there.  Therefore,  it  is  important  that  the  design  team  take  the  time  to 
outline  a  set  of  alternative  architectures  that  may  become  an  interim 
target  until  the  ultimate  target  can  be  legitimately  reached. 

There  are  four  conceptual  levels  of  architecture  that  should  be 
discussed;  these  are  shown  in  Figure  6.  The  “baseline”  is  the 
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architecture  that  already  exists;  the  “migration  path”  could  contain  a 
number  of  configurations  to  be  implemented  over  time  to  reach  the  final 
target  (the  first  of  these  is  known  as  the  “base  system”);  the  “modified 
target  architecture”  is  the  future  architecture  we  may  have  to  settle  for 
due  to  system  or  cost  constraints;  and  the  “ultimate  target  architecture” 
is  where  we  finally  want  to  get. 

This  section  describes  the  overall  process  by  which  the 
architecture  framework  is  extended  by  the  design  team.  The  issues  for 
the  design  team  to  be  concerned  with  during  this  process  include: 

1.  An  extension  of  the  vision  as  described  in  the  “Organize  and 
Plan”  process; 

2.  A  description  of  the  future  enterprise  and  a  desired  future 
architecture  required  to  meet  future  functional  requirements; 

3.  An  identification  of  what  can  be  extended  from  the  current 
environment  into  the  target  environment. 

But  what  can  the  design  team  do  if  no  vision  exists  for  a  future 
architecture?  This  can  be  either  a  blessing  or  a  curse,  depending  upon 


Figure  6:  Four  Levels  of  System  Architecture 
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how  much  effort  the  design  team  (and  the  enterprise)  is  willing  to  put 
forth  on  the  project.  It  is  much  like  an  artist  being  given  a  blank  canvas 
and  told  to  paint  the  future.  If  the  artist  expends  some  effort  in  research, 
he  can  get  very  close  to  the  near  future.  Like  the  artist,  if  the  design 
team  does  its  research,  they  can  target  an  architecture  that  will  normally 
meet  the  enterprise’s  future  needs  But,  without  the  research,  it  is  just  a 
stab  in  the  dark. 

Now,  we  will  take  a  look  at  some  procedures  the  design  team  can 
use  to  design  the  target  architecture.  Here  again,  the  three  views  have 
been  used  to  ensure  all  perspectives  are  considered.  Figure  7  depicts  an 
overall  framework  the  design  team  can  use  while  developing  the  target 
architecture.  As  we  saw  in  the  earlier  phases,  each  view  of  the  target 
architecture  has  some  overlap  with  aspects  of  the  other  views  (see  Figure 
8,  Figure  9,  and  Figure  11,  below).  This  overlap  supports  the  argument 
that  we  are  developing  a  single,  integrated  architecture  [Ref.  8,  p.  4-4]. 
The  design  team  can  frequently  refer  to  this  meta-model  in  order  to 
remain  focused  on  the  key  aspects  of  the  task  at  hand. 
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An  Integrated  Model  with  Component  Relationships 


Figure  7:  Integrated  Model  with  Component  Relationships  (TAFIM  Vol.  4) 
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B.  ORGANIZATIONAL  VIEW 


1.  Changes  to  the  Existing  Organizational  Structure 

The  organizational  structure  can  be  looked  at  in  two  different 
context.  One  is  from  the  task  prospective.  This  includes  the  enterprise 
tasking  and  the  information  flow  required  to  perform  the  functional 
requirements.  The  other  context  is  from  the  enterprise  unit,  or 
command,  structure.  Figure  8  highlights  those  areas  that  the  design 
team  should  keep  in  mind  while  concentrating  on  the  organizational 
view. 


When  evaluating  the  users  systems,  the  tasking  should  be  studied 
in  great  detail  and  changes  recommended  where  appropriate.  This 
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should  be  done  with  complete  disregard  for  the  unit  structure.  [Ref.  8] 

For  example,  suppose  we  are  designing  a  new  centralized  information 
system  for  tracking  cargo  and  shipping  data  for  U.S.  ports.  The  data  is 
normally  supplied  to  Coast  Guard  Headquarters’  (CGHQ)  from  the  VTS  in 
the  form  of  quarterly  reports;  they,  in  turn,  have  gathered  the 
information  from  the  port  authorities.  Looking  at  it  from  the  unit 
structure  context,  we  might  electronically  collect  the  information  from 
the  VTS.  Looking  at  it  from  the  tasking  context,  we  see  that  it  would  be 
more  efficient  to  electronically  collect  the  information  directly  from  the 
port  authorities. 

Although  the  design  team  may  have  very  little  input  into  task 
reassignment,  it  should  still  take  a  broad  look  at  the  tasking  necessary  to 
perform  existing  and  anticipated  future  functional  requirements  and 
make  recommendations  for  change  where  necessary.  In  this  manner,  the 
command  structure  will  have  the  option  to  reengineer  the  tasking  before 
the  new  system  is  put  in  place. 

2.  Determine  Other  Potential  Network  Users 

Depending  on  the  location  and  the  type  of  telecommunications 
network  implemented,  other  government  entities  may  have 
telecommunication  requirements  that  can  be  accommodated  on  a  CG 
owned  network.  Although,  at  this  point  the  type  of  network  to  be 
installed  will  not  be  known,  the  design  team  should  keep  this  in  mind 
when  visiting  the  enterprise  sites.  They  should  inquire  into  any  other 
government  interests  that  are  located  near  the  sites.  Other  government 
entities  would  be  responsible  for  providing  their  signals  to  demarcation 
points  located  at  the  necessary  sites.  They  can  also  be  required  to  share 
in  the  costs  of  the  network.  Since  participation  by  outside  agencies 
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could  affect  the  target  architecture  to  be  chosen,  these  agencies  should 
be  contacted  as  early  as  possible. 

C.  FUNCTIONAL  VIEW 

To  reiterate,  functional  requirements  are  those  functions  which 
must  be  completed  by  the  enterprise  for  their  mission(s)  to  be  a  success. 
We  have  already  researched  the  existing  functional  requirements  during 
the  basic  characterization  phase.  Now,  the  design  team  must  determine 
what  new  functional  requirements  may  be  added  in  the  future.  While  the 
Coast  Guard’s  missions  and  functional  requirements  for  seven  to  ten 
years  from  now  are  not  documented,  there  are  signs  which  point  to  the 
direction  in  that  we  are  heading.  Many  of  these  signs  are  now  being 
posted  by  our  leaders  in  the  Congress,  the  Coast  Guard,  and  the  rest  of 
government. 

Each  of  the  program  offices  in  CGHQ  have  assigned  planning 
staffs.  They  possibly  have  already  gathered  information  from  government 
sources,  industry,  national  and  international  committees  and  combined 
it  with  their  own  plans  for  the  future.  Their  plans  control  the  future  of 
the  network  users.  Therefore,  the  knowledge  contained  within  their 
plans  must  be  captured  and  incorporated  by  the  design  team. 

It  is  up  to  the  project  officer  and  his  command  to  determine  what 
method  is  used  to  gather  this  information.  One  method  would  be  to  hold 
face-to-face  meetings  with  the  subject  experts.  This  is  the  easiest  way  for 
many  people  to  brainstorm  and  participate  in  true  dialogue.  However,  I 
would  recommend  that  before  any  meetings  are  held,  the  project  officer’s 
command  send  a  formal  letter  to  spell  out  the  purpose,  the  plan,  and 
request  an  individual  be  assigned  to  work  with  the  design  team.  This 
will  allow  each  office  to  properly  assign  the  task  and  begin  the  necessary 
research.  This  may  seem  like  an  inordinate  amount  of  work,  but  proper 
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planning  pays  off.  Once  this  information  is  obtained,  meetings  can  be 
held  to  assess  the  impact  on  the  enterprise’s  organization  and  mission 
requirements,  and  negotiate  the  level  of  functional  implementation. 

By  assessing  the  likelihood  of  major  changes  to  the  Coast  Guard, 
and  therefore  the  functions  and  missions,  we  can  better  analyze  the  risks 
of  different  target  architectures.  For  instance,  one  alternative  may  meet 
today’s  requirements,  but  not  be  adaptable  to  future  technology. 

Another  alternative  may  provide  more  versatility  for  the  future,  but  at  a 
higher  cost.  This  assessment  of  functional  and  mission  change  should 
lead  to  a  number  of  different  scenarios,  each  with  its  own  set  of  missions 
and  functional  requirements.  These  scenarios  should  be  deeply 
deliberated  on  by  the  design  team  to  ensure  the  target  architecture 
chosen  will  have  the  highest  probability  of  meeting  the  enterprises  future 
requirements.  Figure  9  highlights  those  areas  that  the  design  team 
should  concentrate  on  while  researching  the  functional  view. 
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Firctional  View 


Figure  9:  Integrated  Model  Highlighting  Functional  View 

The  functional  requirements  of  the  existing  missions  must  be  met 
by  the  base  system  (1st  migration  configuration).  For  each  scenario,  the 
future  functional  requirements  of  each  unit  should  be  compared  to  the 
existing  functional  requirements.  If  they  are  the  same,  or  have 
diminished,  they  may  be  disregarded.  If  different,  they  should  be 
properly  labeled  and  added  to  the  list  of  functional  requirements. 

We  now  have  a  completed  list  of  functional  requirements  which 
include  those  from  the  baseline  characterization  and  the  additional 
functional  requirements  considered  for  the  future.  It  is  now  time  for 
another  round  of  dialogue  and  negotiation  between  the  entities  having  a 
stake  in  the  project.  This  group  must  categorize  the  requirements  into 
one  of  the  three  categories,  “Must  Have,”  “Should  Have,”  or  “Nice  to 
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Have.”  Here  again,  diailogue  and  negotiation  are  the  keys  to  developing 
an  acceptable  plan.  This  category  information  will  be  used  to  develop 
relative  values  for  the  functional  requirements  during  the  following 
phases. 

A  date  indicating  the  year  that  a  functional  requirement  will  be 
required  should  be  attached  to  each  requirement.  The  configuration 
shown  in  Figure  10  will  be  used  here  to  represent  each  functional 
requirement.  This  notation  will  be  very  useful  during  the  follow-on 
phases. 


Fn 

F:  the  function 

n:  the  assigned  function  number 

a:  the  category  the  function  is  assigned  to  (i.  e. ,  1,  2,  3) 

b:  the  year  the  function  is  required 

Figure  1 0:  Symbol  Configuration  Representing  Functional  Requirements 

Determining  the  final  categories  for  each  requirement,  and  the 
date  each  is  required,  will  take  a  considerable  amount  of  dialogue  and 
negotiation.  The  project  officer  must  facilitate  this  dialogue  between  the 
program  managers,  the  commands,  and  the  different  levels  of  users.  His 
role  is  critical  if  the  final  systems  are  to  be  the  most  efficient  and  effective 
available.  The  final  categories  and  dates  for  each  functional  requirement 
may  depend  upon  the  results  of  the  cost/ effectiveness  analysis 
performed  in  the  next  phase.  Another  round  of  negotiations  may  be 
necessary  at  that  time.  But  for  now  we  will  assume  they  will  not  change. 
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D.  PHYSICAL  VIEW 

The  areas  the  design  team  should  be  concerned  with  while 


Physical  View 


Figure  1 1:  Integrated  Model  Highlighting  the  Physical  View 

concentrating  on  the  physical  view  are  highlighted  in  Figure  1 1. 

While  developing  the  target  architecture’s  physical  view,  what  is 
important  is  the  underlying  architecture,  not  particular  equipment  suites 
or  software  bundles.  To  define  the  target  architecture,  TAFIM  uses  the 
terms  Generic  Application  Environments  (GAE),  Generic  Technology 
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Environments  (GTE),  and  Generic  Technology  Platforms  (GTP).i  The  six 
GTP’s  and  examples  of  GAE’s  and  GTE’s  can  be  found  in  Table  3.^ 

In  the  absence  of  promulgated  standards,  the  design  team  must 
choose  the  standards  to  be  incorporated.  To  implement  a  standards- 
based  infrastructure,  it  is  important  to  consider  the  scope  and  depth  of 
the  standards  to  be  adopted.  Fundamentally,  all  cases  of  standards 
adoption  require  answering  three  questions: 

1.  What  standards  should  we  adopt? 

2.  Where  in  our  architecture  should  we  adopt  them? 

3.  When  should  we  adopt  them? 

Standards  should  be  selected  for  the  users  systems,  as  well  as  the 
telecommunications  network.  TAFIM,  Volume  2,  should  be  used  in  this 
phase.  It  suggests  a  standards-based  model  with  sections  for  user 
interface,  database,  applications,  operating  system,  communications, 
languages,  management,  and  other  services.  The  design  team  must  be 
prepared  to  define  the  details  that  underpin  each  of  the  above  sections  of 
the  model  required  for  project  implementation.  TAFIM,  Volume  4, 
Appendix  C,  can  also  be  a  good  reference  point  for  teams  attempting  to 
define  the  details  of  the  standards  model.  [Ref.  8,  p.  4-28] 


1  TAFIM,  VoL  4,  Appendix  D  contains  complete  definitions  for  these  terms. 

2  An  abbreviated  definition  for  each  of  the  GAE’s,  GTE’s,  and  GTP’s  listed  can  be  found  in  the 
Glossary. 
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Table  3:  Examples  of  GAB,  GTE,  &  the  Six  GTP 


GAE 

QTE 

GTP 

Batch  processing 

User  interface  services 

Intelligent  Wide  Area 

Transaction  processing 

System  management  services 

Network  Systems 

Inquiry  processing 

Communications  management 

Decision  support 

services 

Expert  systems 

Database  management 

Establishment-based 

Real-time  control 

services 

Switching  Systems 

Text  processing 

Hypermedia 

Document  processing 

Transaction  media  services 

Electronic  publishing 

Document  management 

Local  Area  Network  Systems 

Hypermedia  processing 

services 

Video  processing 

Conferencing  management 

Document  storage  &  retrieval 

services 

Enterprise  or  Corporate 

Electronic  mail 

Distribution  services 

Processing  Systems 

Voice  mail 

Repository  services 

Enhanced  telephony 

Repositories  for  system 

Shared  screen  teleconferencing 

construction 

Divisional  or  Departmental 

Video  teleconferencing 

Repositories  for  systems 

Processing  Systems 

Broadcast 

management 

Computer  conferencing 

Sender  definitions 

Name  server 

Desktop  or  Portable 

Authentication  server 

Access  control  server 

Cryptographic  server 

Communications  server 

Time  server 

File  server 

Data  server 

Print  server 

Mail  server 

EDI  translation  server 

Applications  server 

Presentation  server 

Sensor  monitor/ actuator 

server 

Intelligent  Workstations 
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1.  Requirements  VS.  Technical  Capabilities  VS.  Sites 

Once  the  functional  requirements  for  the  users  systems  have  been 
determined,  they  must  be  matched  to  the  technical  capabilities  necessary 
to  provide  them.  A  matrix  of  Functional  Requirements/Technical 
Capabilities  should  be  developed.  An  example  of  such  a  matrix  can  be 
seen  in  Table  4.  An  “X”  placed  in  the  column  of  a  requirement  and  the 
row  of  a  technical  capability  signifies  that  the  technical  capability  must 
be  provided  if  the  functional  requirement  is  to  be  met. 


Funciionai  Requirement  (Fn)/Tecfanical  Capability  (TC)  Table 

Fanctional  Reqniremeats  (Fno,i.;ye»rreqBiTe<i) 

^^3:95 

^^^3:96 

F5j^3 

^li9S 

TCI 

X 

X 

HI 

X 

■i 

TC2 

X 

iiiiiii 

X 

X 

X 

TC3 

X 

X 

X 

•  » 

X 

TC4 

X 

X 

X 

X 

■ 

X 

TC5 

X 

liM 

X 

HBI 

■i 

'  •  • 

•  •  • 

... 

iiiigiii 

... 

TCb 

X 

X 

mm 

H 

Table  4:  Functional  Requirements/ Technical  Capabilities  Matrix 


At  the  same  time,  a  matrix  depicting  the  relationship  of  technical 
capabilities  and  enterprise  sites  should  be  constructed.  A  suggested 
symbol  configuration  can  be  seen  in  Figure  12.  With  this  configuration, 
we  can  tell  at  a  glance  what  category  of  functionality  has  been  called  for 
and  what  is  the  earliest  year  for  implementation. 
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TCn 


a:b-c 


TC:  technical  capability  designator 
n:  the  assigned  TC  number 
a:  the  highest  functionality  category  of  the  TC 
(i.e.,  1,2,  3) 

b;  the  earliest  year  the  TC  is  required;  for  the  highest 
level  of  functionality 

c:  the  earliest  year  the  TC  is  required  for  lower  level 
of  functionality  (if  earlier  than  b) 


Figure  12:  Symbol  Configuration  Representing  Technical  Capability 


Table  5  illustrates  the  Site/Technical  Capability  Matrix.  The 
technical  capabilities  inherit  their  functionality  categories  and 
implementation  year  designators  from  the  functional  requirements  with 
the  highest  assigned  functionality  category  they  correlate  to.  If  the  date 


Table  5:  Site/ Technical  Capability  Matrix 
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of  a  lower  category  is  earlier  than  the  higher  category,  a  second  year 
designator  is  added  to  the  symbol. 

For  example,  TC2  has  a  category  one  requirement  for  “98,”  but  it 
also  has  a  category  two  date  for  “95.”  Therefore,  the  complete  symbol 
would  be  “TC2 1:98-95.”  Note  that  if  the  functionality  is  category  one,  the 
date  can  only  be  moved  earlier;  if  it  is  category  two  or  three,  the 
implementation  date  is  negotiable  either  earlier  or  later.  Instead  of  filling 
the  correlation  box  with  an  “X,”  the  box  is  marked  with  the  date  chosen 
for  implementing  that  technical  capability  at  that  particular  site.  These 
dates  can  be  changed  in  order  to  come  up  with  the  most  cost-efficient 
implementation  schedule  (depending  upon  functionality  requirements 
and  network  implementation. 

The  purpose  for  these  matrices  is  to  help  the  design  team,  users, 
and  reviewers  track  the  required  functionality  and  technology  in  a 
systematic  manner.  It  simplifies  the  process  of  documenting  which 
functional  requirements  drive  which  technical  capabilities  and  at  what 
sites  the  technical  capabilities  are  required.  It  will  assist  in  tracking  how 
many  equipment  suites  must  be  planned  for  and  how  much  space  will  be 
necessary  at  each  particular  site. 

Once  the  above  process  has  been  completed  for  the  users  systems, 
the  same  type  of  matrices  should  be  constructed  for  the 
telecommunications  network.  These  will  be  very  useful  to  all  those  who 
participate  in  the  functional/ technical  dialogue  and  assist  the  design 
team  while  dealing  with  system  migration  during  the  next  two  phases. 
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E.  THE  BAGS  TARGET  ARCHITECTURE 

1.  Organizational 

With  the  new  CG  streamlining  measures  coming  into  effect  [Ref. 
12],  the  BAGS  design  team  has  it  is  job  cut  out.  Many  of  the  missions, 
functions,  and  workflows  for  a  number  of  the  BAGS  user  commands  will 
be  affected  (i.e.,  growth  of  MLGP,  dismantling  of  D1 1,  new  PAGAREA 
responsibilities,  etc.). 

Because  the  streamlining  measures  are  causing  changes  in  the 
“system,”  the  BAGS  project  has  actually  come  at  an  opportune  moment. 
As  we  discussed  in  chapter  one,  one  biggest  stumbling  block  to 
implementing  change  is  overcoming  the  resistance.  In  this  case,  the 
“system”  is  already  facing  mandatoiy  change.  With  the  investment  of 
some  resources,  PAGAREA  and  MLGP  have  the  perfect  opportunity  to  re¬ 
engineer  some  of  the  more  ineffective  or  inefficient  workflows.  This  could 
lead  to  much  greater  savings  in  the  future. 

Even  if  the  command  structure  does  not  take  advantage  of  this 
opportunity,  the  design  team  must  still  re-evaluate  the 
telecommunication  needs  for  each  of  these  units.  This  is  critical  if  they 
are  to  design  a  network  capable  of  serving  this  newly  organized 
enterprise,  today,  and  into  the  future. 

There  is  the  possibility  the  BAGS  network  could  be  used  by  other 
government  agencies.  Many  of  the  remote  sites  are  located  next  to 
equipment  owned  by  the  Navy,  Forest  Service,  Federal  Aviation 
Administration,  and  others.  These  agencies  should  be  spoken  with 
before  the  project  gets  too  far  into  the  planning  stage. 

2.  Functional 

The  BAGS  network  is  a  veiy  large,  complex  project.  The  required 
functionality  of  the  different  user  commands  covers  the  scale  from  one 
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end  to  the  other.  Due  to  this  size  and  complexity,  the  project  officer 
should  implement  a  procedure,  like  the  procedures  suggested  above,  to 
track  and  document  the  project. 

The  opinions  on  the  required  level  of  functionality  vary  in  the  same 
way.  Because  the  political  level  of  functionality  is  above  that  of  the 
project  officer,  he  must  assume  the  role  of  facilitator.  He  must 
encourage  dialogue  and  lead  the  entities  involved  to  a  consensus.  The 
group  must  be  willing  to  explore  new  possibilities  and  work  together  for 
the  good  of  the  whole  enterprise. 

3.  Physical 

With  all  the  recent  changes  in  the  telecommunications  industry, 
we  must  be  careful  not  to  lock  ourselves  into  a  given  technology  or  way  of 
doing  business  because  “that  is  the  way  it  is  always  been  done.”  If  this 
occurs,  we  will  be  limiting  our  opportunities  to  take  advantage  of  the 
before-mentioned  advances. 

F.  CONCLUSION 

By  using  the  Structured  Approach  Model,  we  have  systematically 
completed  the  following: 

1.  We  have  considered  the  CG-wide  visions  and  strategy  for  which 
our  project  can  help,  or  hinder,  implementation. 

2.  We  have  defined  the  problem  by  listing  the  visions  and 
operational  requirements  which  cannot  be  met  by  the  system 
along  with  any  existing  limitations  or  discrepancies  with  the 
physical  structure  which  justify  replacement. 

3.  We  have  drawn  a  limited  picture  of  “where  we  are”  with  respect 
to  user  systems  by  inventorying  the  physical  sites  and 
resources,  studying  work-flow  patterns,  and  collecting  user 
requirements.  We  have  drawn  the  same  kind  of  picture  for  the 
existing  telecommunications  network  by  inventorying  the  sites 
and  resources,  stud3dng  the  existing  circuits  and  network 
management  techniques. 
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4.  We  have  determined  “where  we  want  to  go”  by  attempting  to 
collect  future  requirements,  by  considering  possible  changes  to 
organizational  structure  and  business  processes,  and  by 
determining  a  standards-based  system  architecture  that  can 
meet  the  functional  requirements  independent  of  a  specific 
technology  implementation.  We  have  also  developed  a  matrix 
that  correlates  the  functional  requirements  with  the  technical 
capabilities  required  to  implement  them  and  a  matrix  that 
correlates  the  technical  capabilities  to  the  sites  (correlates 
technical  capabilities  for  both  the  user  systems  and  the 
telecommunications  network). 
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VI.  GENERAL  COMMUNICATION 
SERVICES  &  TECHNOLOGIES 


A.  INTRODUCTION 

The  purpose  of  this  chapter  is  to  review  some  of  the  basic 
communication  services,  protocols,  and  technologies  available  today.  To 
complete  the  target  architecture,  the  design  team  must  have  an 
understanding  for  the  technology  that  is  available  today  and  where 
technology  is  headed  tomorrow.  They  should  possess  a  working  level 
iinderstanding  of  the  existing  de  jure  standards  and  the  architectures 
which  form  their  foundations. 

This  chapter  provides  a  broad  discussion  of  basic  communications 
engineering  concerns  and  some  of  the  more  prevalent  architecture 
standards  and  transmission  media  available  today. 

The  block  diagram  of  a  general  communication  system  is  given  in 
Figure  13.  The  basic  problem  faced  when  designing  a  communication 
system  can  be  viewed  from  two  different  aspects.  These  two  views 
include  designing  a  communications  system  that: 

1 .  Uses  a  given  transmission  channel  as  effectively  as  possible. 
This  means  that  the  channel  should  convey  the  maximum 
possible  amount  of  information  in  the  time  permitted, 
consistent  with  the  noise  introduced  and  the  error  in  the 
received  message  that  can  be  tolerated  [Ref.  14].  This  view  deals 
with  channel  effectiveness. 

2.  Provides  the  most  economical  channel  to  use  with  the  given 
message,  consistent  with  the  noise  sources  and  the  allowable 
error  rate.  The  choice  of  the  method  of  coding,  as  well  as  the 
design  of  all  the  components  in  the  coder,  channel,  and 
decoder,  must  be  considered  to  overcome  these  limitations. 

This  view  deals  with  channel  efficiency. 
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In  this  diagram  we  can  introduce  either  a  wired  or  wireless  system 
in  the  transmission  channel  as  a  means  of  transmission  interconnection. 
Telephone  lines  are  an  example  of  a  wired  interconnection,  while  cellular, 
microwave,  and  satellite  systems  are  examples  of  wireless  systems. 


72 


73 


B.  THE  BASICS  OF  COMMUNICATIONS 

In  any  communication  system  information  to  be  transmitted  is 
generally  available  in  the  form  of  an  electrical  signal  that  may  take  one  of 
two  forms:  an  analog  or  a  digital  signal.  In  the  analog  case,  the  signal 
(e.g.,  electric  current)  varies  continuously  with  time,  as  shown 
schematically  in  Figure  14(a).  In  the  case  of  a  digital  signal,  the  signal 
will  normally  have  one  of  two  (and  sometimes  three)  voltage  values. 

These  values  represent  the  digital  bits  "0"  and  "1"  (bit  stands  for  binary 
digit),  as  shown  schematically  in  Figure  14(b). 

An  analog  signal  can  be  converted  into  digital  form  by  sampling  it 
at  regular  intervals  of  time.  Communications  by  digital  signaling  is  an 
increasingly  important  technique  for  radio  communications.  With  the 
exception  of  slow  (below  56  Kbps)  dial-up  circuits  using  modems,  most 
WAN  connections  use  digital  transmission.  Therefore,  this  discussion 


Figure  1 4:  Representation  of  a)  an  Analog  Signal  &b)  a  Digital  Signal 


74 


will  focus  on  digital  transmission  techniques. 

Digital  transmission  has  a  number  of  advantages  over  other 
techniques  [Ref.  15  ].  These  include  : 

1 .  the  ease  and  efficiency  of  multiplexing  multiple  signals  or 
handling  digital  messages  in  "packets"  for  convenient  switching; 

2.  the  relative  insensitivity  of  digital  circuits  to  re-transmission 
noise,  commonly  a  problem  with  analog  systems; 

3.  potential  for  extremely  low  error  rates  and  high  fidelity  through 
error  detection  and  correction; 

4.  communications  privacy; 

5.  the  flexibility  of  digital  hardware  implementation,  which  permits 
the  use  of  microprocessor,  digital  switching,  and  the  use  of 
large-scale  integrated  circuits. 

Digital  transmission  techniques  require  an  analog-to-digital 
interface  (or  vice-versa)  when  the  original  form  of  the  information 
transmitted  is  aneilog. 

There  are  three  basics  required  for  data  communications  [Ref.  16]: 

1 .  a  physical  connection; 

2.  a  set  of  data  communication  functions  performed  by 
participating  computers; 

3.  use  of  common  protocol  for  each  communication  function. 

1.  Physical  Connection 

Physical  connections  can  be  provided  over  many  types  of 
transmission  media  (e.g.,  twisted  pair,  coax,  microwave).  Connections 
are  made  either  over  a  dedicated  link  or  through  a  switched  network. 
Types  of  networks  will  be  discussed  further  in  section  b4-b7. 


2.  Communication  Functions 

The  following  are  communication  functions  which  must  be 
performed  by  participating  network  computers: 

1.  information  encoding; 

2.  encryption/ compression; 

3.  session  management; 

4.  error  and  flow  control  -  from  originating  point,  across 
network{s),  to  destination 

5.  interaction  with  network; 

6.  error  and  flow  control  -  across  each  link  between  nodes; 

7.  bit  encoding. 

Due  to  the  complexity  of  implementing  the  above  functions, 
standard  data  communication  architectures  have  been  developed  to 
decompose  these  functions  into  more  manageable  modules  and  define 
interaction  between  the  modules.  The  four  standard  architectures 
include: 

1.  IBM’s  System  Network  Architecture  (SNA)  -  proprietary; 

2.  dec’s  Digital  Network  Architecture  (DNA)  -  proprietary; 

3.  ISO’  Open  Systems  Interconnection  (OSI)  -  open  standard; 

4.  DOD’s  TCP/IP  Architecture  -  open  standard. 

This  discussion  will  focus  on  the  open  standard  network  architectures 
(i.e.,  OSI,  TCP/IP)  since  these  are  the  standards  used  widely  by  the  U.  S. 
government. 


®  These  are  unnecessary  for  dedicated  connections. 
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Each  of  the  communication  functions  mentioned  above  are 
contained  -within  one  of  the  layers  of  each  architecture.  This  can  be  seen 
in  Table  6.  Each  architecture  layer  uses  protocols  to  specify  how  the 
functionality  is  to  be  provided. 


Table  6:  Association  of  Communication  Functions  with  Architecture  Layers 


OSI  Architecture 

Communication 

Function 

DOD’s  TCP/IP 
Architecture 

Layer  7:  Application 

Information  Encoding 
(specific  applications; 
such  as  Email,  File 
Transfer,  etc.) 

Layer  4;  Upper  Layer 

Layer  6:  Presentation 

Encryption  /  Decryption 

Layer  4:  Upper  Layer 

Layer  5:  Session 

Session  Management 

Layer  4:  Upper  Layer 

Layer  4:  Transport 

Error  and  Flow  Control 
(across  networks) 

Layer  3: 

Transmission  Control 

Layer  3:  Network 

Interaction  with 
Network 

Layer  1: 

Network  Access 

86  Layer  2:  Internet 

Layer2: 

Data  Link  Layer 

Error  and  Flow  Control 
(across  a  link) 

Layer  1: 

Network  Access 

Layer  1:  Physical 

Bit  Encoding 

Layer  1; 

Network  Access 

3.  Protocols 

Standards  (also  known  as  protocols)  based  on  the  OSI  architecture 
are  developed  by  a  voluntaiy  group  called  “International  Standards 
Organization  (ISO).”  These  standards  are  then  massaged  and  given 
formal  authority  by  the  International  Consultative  Committee  on 
Telegraphy  and  Telephony  (CCITT),  which  is  part  of  the  United  Nations. 
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The  OSI  architecture  consists  of  seven  layers.  The  networking  protocols 
are  contained  within  the  first  four  layers. 

The  United  States  Department  of  Defense  (DOD)  developed  the 
TCP/IP  network  architecture.  It  consists  of  four  layers.  The  networking 
protocols  are  contained  within  the  first  two  layers  (these  correspond  to 
the  first  four  OSI  layers).  The  OSI  and  TCP/IP  architectures  are 
compared  in  Figure  15. 

Each  layer  has  specific  protocols  for  specific  purposes.  For 
example,  EIA  232-D  can  be  used  for  the  OSI  physical  layer.  This 
protocol  defines  the  following  five  things: 

1 .  electrical:  uses  NRZ-L  bit  encoding  scheme; 

2.  physical  connector:  RS  232  25  pin  connector; 

3.  functional:  assigns  each  connector  pin  a  given  function; 

4.  procedural:  specifies  what  computing  equipment  will  do  when 
it  has  a  task  to  complete  or  when  it  receives  a  given  signal  on  a 
given  connector  pin;  example:  when  the  Data  Terminal 
Equipment  (DTE)  has  data  to  send  it  will  apply  high  voltage 
(<3V)  on  pin  #4,  when  the  Data  Circuit-terminating  Equipment 
(DCE)  receives  high  signal  on  pin  #4,  it  acknowledges  with  a 
high  signal  on  pin  #5. 

5.  constraints:  distance  between  DTE  and  DCE  is  limited  to 
approximately  50  ft  (15m);  limit  of  20Kbps  between  DTE  and 
DCE. 


78 


int^net 


3)i)>elwotk 


Network  Acce^ 


Figure  15:  OSI  &  TCP/IP  Architectures  with  Examples  of  Associated  Protocols 


There  are  also  protocols  which  span  across  architecture  layers. 
These  protocols  are  for  specific  types  of  networks  and  incorporate  various 
protocols  from  each  layer.  For  example,  X.25  spans  the  physical  layer, 
data  link  layer,  and  half  the  network  layer  of  the  OSI  model.  It  consists 
of  the  following  protocols  at  layers  1-3  [Ref.  16]: 

1.  Layer  3:  X.25  Packet  Layer  Protocol  (PLP); 


Essamples  of 
OSI  specific 

protocols  Ar^ttecture 

FTAM,  '  •  • 

X.500  '■  ■ 


ESsample 
of  shared 
protocols 

X.400  & 
X.500 

(with  adjustments) 


TCP/IP 

Architecture 


Eaiamples 
of  TCP/IP 
protocols 


SMTP. 


Telnet 


ISO  8062, 
ISO  8073: 
TP  classes 
TP0-TP4 

ISO  8473:  CLNP 


IS07776:HDLC  2)DataUnk 


EIA232-D 

EIA530  hPhyacal 


7  layers 


4  layers 
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2.  Layer  2:  Link  Access  Protocol  “B”  (LAP-B); 

3.  Layer  1:  X.21  or  EIA  232-D. 

Some  of  these  protocols  can  be  applied  under  either  architecture, 
X.25  is  a  good  example.  If  X.25  is  used  with  the  TCP/IP  model,  protocols 
for  the  internet,  transmission,  and  upper  levels  would  be  applied.  If  X.25 
is  used  with  the  OSI  model,  the  CLNP  protocol  is  applied  to  complete  the 
network  layer,  then  protocols  for  layers  4-7  are  applied. 

4.  Types  of  Communication  Networks 

So  why  are  there  so  many  protocols?  The  protocols  chosen  to 
perform  the  functions  of  the  different  layers  depend  on  the  type  of  data 
sent,  the  type  of  network  used  to  send  it,  and  the  method  for  completing 
each  function  that  the  engineer  considers  best  for  the  situation.  Since 
the  protocols  dealing  with  the  telecommunications  network  are  contained 
within  the  first  four  OSI  levels  (first  two  TCP/IP  levels),  we  will  limit  the 
following  discussion  to  those  levels.  Sections  b5  -  bS  correspond  to  the 
first  four  layers  of  the  OSI  model;  they  briefly  describe:  1)  the  different 
types  of  circuits  and  2)  the  methods  for  implementing  the 
communications  functions  assigned  to  that  architecture  layer. 

5.  Physical  Layer 

As  discussed  earlier,  there  are  two  types  of  data:  1)  analog,  and  2) 
digital.  The  analog  data  can  come  from  an  analog  source  (i.e.,  voice, 
multimedia)  or  it  can  be  digital  information  converted  to  analog  by  a 
modem.  Analog  data  can  only  be  carried  on  broadcast  networks.  Recall, 
these  are  networks  which  contain  fixed,  or  dedicated,  paths  from  sender 
to  receiver.  Digital  information  can  come  from  a  digital  source  (e.g., 
computer,  ISDN  telephone)  or  can  be  analog  information  that  has  been 
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digitized.  Digital  data  can  be  carried  on  either  broadcast  or  switched 
networks. 

To  compensate  for  loss  of  signal  strength  over  long  distances, 
analog  circuits  normally  contain  amplifiers  at  intermediate  points  to 
boost  signal  strength.  In  addition  to  boosting  signal  strength,  the 
amplifiers  also  boosts  any  noise  that  has  been  introduced  to  the  signal. 
As  the  signal  travels  from  amplifier  to  amplifier,  more  noise  is 
introduced,  and  subsequently  amplified.  This  leads  to  a  drop  in  the 
Signal-To-Noise  ratio,  a  measurement  of  signal  degradation.  Digital 
circuits  incorporate  repeaters  instead  of  amplifiers.  As  long  as  the  digital 
signal  is  strong  enough  to  recognize  the  individual  bits  are  recognizable, 
the  repeater  regenerates  the  signal  faithfully  and  sends  it  on.  This 
prevents  any  noise  introduced  to  the  signal  from  being  passed  on  from 
link  to  link. 


6.  Data  Link  Layer 

The  Data  Link  Layer  is  responsible  for  reliable  transmission  of  data 
across  a  single  switched  network  link,  or  from  point-to-point  across  a 
broadcast  network.  There  are  three  controls  that  lead  to  reliabilily: 

1.  error  control; 

2.  flow  control  (at  message  level); 

3.  access  control  (at  network  level). 

We  will  discuss  various  methods  used  to  apply  error  and  flow  control. 
Access  control  applies  mainly  to  LAN’s;  therefore,  it  is  beyond  the  scope 
of  this  paper. 

There  are  three  types  of  error  detection  used  in  the  DLL:  1)  Parity 
Check,  2)  Two-dimensional  Parity  Check  (LRC  and  VRC),  and  3)  Cyclical 
Redundancy  Check  (CRC).  To  provide  error  and  flow  control,  the  signal 
binary  bits  must  first  be  packaged  with  the  overhead  bits  into  frames. 
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There  are  three  frame  formats,  depending  on  what  the  signal  data  is 
oriented  to:  1)  Asynchronous,  2)  Character-oriented  Synchronous,  and  3) 
Bit-oriented  Synchronous.  Figure  16  (a,  b,  c)  depict  the  various 
segments  of  each  t5rpe  of  frame.  If  an  error  is  detected,  re-transmission 
of  frame  is  requested. 


Start  Bit 

5-8  Bits 

Parity  Bit 

1-2  Stop  Bit(s) 

I 

FRAME 

a)  Asynchronous 


Sync.  Char. 

Control  Char. 

Data  Char,  (mulitples  of  8  bits) 

Control  Char. 

Sync.  Char. 

FRAME  CHECK  SEQUENCE 


FRAME  CHECK  SEQUENCE 

b)  Character-Oriented  Synchronous 


011011001 

Control  Field. 

Data  Field  (any  number  of  bits) 

Control  Field 

011011001 

^  /|v 

FRAME  CHECK  SEQUENCE  FRAME  CHECK  SEQUENCE 

|(Pre-Defined  Sequence)  (Pre-Defined  Sequence) 

_ c)  Bit-Oriented  Synchronous _ 


r 


t 


Figure  16:  Frame  Formats  for  Digital  Signals 


There  are  two  methods  used  for  flow  control:  1)  Stop  8s  Wait,  and  2) 
Sliding  Window.  Under  the  Stop  85  Wait  method,  the  sending  DTE  sends 
one  frame  and  waits  for  the  receiving  DTE  to  send  a  “received” 
acknowledgment.  Once  the  acknowledgment  is  received  by  the  sender, 
the  sender  will  send  the  next  frame,  and  so  on.  The  Sliding  Window 
utilizes  a  First-in/ First-out  (FIFO)  buffer  in  the  receiving  DTE.  The 
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sending  DTE  begins  sending  frames,  not  waiting  for  “received” 
acknowledgments.  The  “window”  is  the  number  of  frames  the  sending 
DTE  will  send  out  before  stopping  and  waiting  for  “received” 
acknowledgments  to  return.  As  the  receiving  DTE  receives  the  frames, 
they  are  placed  in  the  FIFO  buffer.  As  the  receiving  DTE  processes  the 
frames,  it  sends  acknowledgments  back  to  the  sender.  If  more  frames 
arrive  than  the  buffer  can  hold,  they  are  automatically  discarded.  The 
sending  DTE  will  send  the  number  of  frames  specified  for  the  “window.” 

If  it  still  has  not  received  acknowledgment  for  the  first  frame  in  the 
window,  it  will  time-out  and  automatically  re-send  that  frame. 

If  an  acknowledgment  is  lost,  the  sender  will  continue  to  send 
frames  until  the  “window”  limit  is  reached.  It  will  then  time-out  and 
automatically  re-send  the  unacknowledged  frame.  When  the  receiving 
DTE  receives  the  same  frame  a  second  time,  it  will  send  a  second 
acknowledgment,  then  throw  away  the  frame  (since  that  particular  frame 
was  already  processed  the  first  time  it  was  sent). 

If  the  receiving  DTE  detects  an  error  (using  parity  or  CRC 
checking),  it  will  pass  the  frame  back  to  the  flow  control.  This  will  cause 
a  negative  acknowledgment  to  be  sent  back  to  the  sending  DTE.  Upon 
receipt  of  the  negative  acknowledgment,  the  sending  DTE  will  re-send  the 
frame. 

There  is  one  more  set  of  optional  methods  that  can  be  applied 
under  the  “Sliding  Window”  method.  These  methods  are  called  “Selective 
Repeat,”  and  “Go  Back-N.”  Anytime  the  receiving  DTE  has  to  send  a 
negative  acknowledgment,  the  following  will  occur  under  the  two 
methods: 

1 .  Selective  Repeat  -  The  receiving  DTE  will  keep  all  additional 
frames  it  receives  until  the  bad  frame  is  received  correctly 
(provided  the  buffer  has  enough  room). 
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2.  Go  Back-N  -  Once  a  negative  acknowledgment  has  been  sent, 
the  receiving  DTE  will  dump  all  incoming  frames  until  the  bad 
frame  is  received  correctly. 

An5dime  the  sending  DTE  times  out,  the  following  will  occur  under 
the  two  (subjmethods: 

1 .  Selective  Repeat  -  The  sending  DTE  will  re-send  only  the  frame 
that  caused  it  to  time-out.  The  receiving  DTE  will  keep  all 
additional  frames  it  receives  until  the  frame  causing  the  time¬ 
out  is  received. 

2.  Go  Back-N  -  Once  the  sending  DTE  times  out,  the  sending  DTE 
will  begin  re-sending  all  frames,  beginning  with  the  frame  that 
caused  the  time-out.  If  the  receiving  DTE  had  received  all  the 
frames,  it  will  dump  them  the  repeated  frames  the  second  time 
they  are  received. 

Table  7  summarizes  the  available  Frame  Format/ Error 
Control/Flow  Control  combinations.  As  an  example,  the  OSI’s  High-level 
Data  Link  Control  (HDLC)  uses  the  following  combinations: 

“HDLC  =>  Bit-oriented  Synchronous  CRC  -»  Sliding  Window.” 


Table  7:  Data  Link  Layer  Frame  Format/ Error  Ss  Flow  Control  Combinations 


Frame  Format 

Error  Control 

Flow  Control 

Asynchronous 

Parity  bit 

Stop  &  Wait 

Character-oriented  Synchronous 

Stop  &  Wait 

LRC  or  CRC 

or 

Sliding  Window 

Bit-oriented  Synchronous 

CRC 

Stop  &  Wait 

or 

Sliding  Window 

7.  Network  Layer 

This  section  is  mainly  edited  and  abbreviated  from  Ref.  16.  As 
mentioned  before,  the  communication  functions  contained  within  the 
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network  layer  are  not  needed  for  broadcast  or  dedicated  networks.  The 
network  layer  is  responsible  for  interaction  with  a  “switched  network” 

(i.e.,  circuit- switched,  packet-switched,  or  fast  packet- switched  network) 
or  a  group  of  networks.  The  protocols  contained  within  the  network  layer 
define: 

1 .  the  format  of  messages  (or  packets)  deliverable  across 
network{s); 

2.  how  each  message  (or  packet)  format  incorporates  “connection- 
oriented”  or  “connectionless”  network  services; 

3.  which  message  (or  packet)  formats  initiate  and  terminate 
network  connections; 

4.  what  each  message  (or  packet)  format  does  when  messages  (or 
packets)  are  lost  or  damaged  within  the  network  (i.e.,  error  and 
flow  control  across  the  network). 

After  defining  how  “connection-oriented,”  “connectionless,”  and 
“fast-packet  switching  (FPS)”  network  services  interact  with  networks, 
this  section  will  discuss  the  various  message  (or  packet)  formats 
including  their  benefits  and  constraints.  We  will  then  use  the  X.25 
protocol  to  illustrate  how  the  sub-protocols  (protocols  contained  within 
different  levels  of  the  X.25  protocol)  apply  the  characteristics  of  the 
packet  format  and  network  service. 

a.  “Connection-oriented”  VS.  “Connectionless”  Service 

The  two  types  of  switched  networks  consist  of  “Connection- 
oriented”  and  “Connectionless.”  Both  services  share  one  trait,  both  use 
what  is  called  “store  and  forwsird”  message  delivery.  This  simply  means 
that  the  message,  or  packet,  is  passed  from  network  node  to  network 
node;  at  each  node,  the  message  (package)  is  stored  in  either  memory  or 
on  disk  until  the  node  can  transmit  the  message  (package)  on  to  the  next 
node. 


85 


Connection-oriented  service  is  also  known  as  “virtual  circuit 
service.”  This  network-layer  service  goes  through  three  stages:  1) 
establishes  connection,  2)  transfers  data,  and  3)  disconnects  connection. 
Rather  than  establishing  a  dedicated  circuit,  it  establishes  a  “logical 
circuit”;  this  means  that  all  the  data  packets  will  pass  through  the  same 
nodes  until  finally  reaching  the  destination.  This  type  of  service  does  the 
following: 

1 .  it  assures  that  the  packets  will  arrive  in  the  same  order  as  sent; 

2.  it  allows  the  network  nodes  to  request  re-transmission  as  soon 
as  a  packet  is  lost  or  damaged; 

3.  the  nodes  can  pass  the  packets  to  the  next  node  faster  because 
it  does  not  have  to  strip  the  frame  from  the  data  and  repackage 
it  in  a  frame  containing  the  next  node  address; 

4.  it  allows  other  data  from  various  sources,  to  use  the  same  lines; 
thus  providing  greater  line  efficiency. 

Connectionless  services  come  in  two  flavors:  message- 
switched  and  datagram.  Connectionless  services  do  not  use  the  same 
path  for  an  entire  session  like  the  connection-oriented.  Instead  each 
node  makes  a  decision  based  on  information  it  receives  from  the 
surrounding  nodes.  Each  node  chooses  the  “least  cost”  node  out  of  the 
nodes  that  are  available.  The  network  control  center  decides  which  node 
is  the  best  alternative  (least-cost).  This  decision-making  has  nothing  to 
do  with  the  network  layer. 

The  message-switched  service  passes  the  whole  message  at 
one  time.  Once  the  message  is  received  at  a  node,  it  is  temporarily 
stored  on  disk  and  then  passed  on  to  the  next  available  “least-cost”  node. 
Since  messages  can  vaiy  to  practically  any  length,  the  delay  at  each  node 
(consisting  of  receiving  time  plus  queuing  delay  time)  will  be  relatively 
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long  and  highly  variable.  This  makes  message-switching  inappropriate 
for  real-time  or  interactive  systems. 

Datagram  services  send  packets  of  data;  they  also  limit  the 
size  of  each  packet.  This,  in  turn,  limits  the  delay  experienced  at  each 
node.  The  packets  are  small  enough  to  be  stored  in  memory  rather  than 
on  disk.  However,  since  each  packet  is  sent  to  the  next  “least-cost”  node, 
and  does  not  follow  a  given  route,  the  packets  can  arrive  at  the 
destination  out  of  order.  Table  8  sums  up  the  differences  between  the 
connection-oriented  and  connectionless  services. 
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Table  8:  Network  Layer  Services  Summary 
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b.  Fast-Packet  Switching  (FPS)  Services 

Fast-packet  switching  (FPS)  services  are  connectionless 
services  that  utilize  permanent  virtual  circuits  (PVC)  established  by  the 
network  manager.  FPS  includes  both  frame-relay  and  cell-relay 
technologies.  They  are  designed  for  high  throughput  and  low  traffic 
delay  while  retaining  the  efficient  line-sharing  of  regular  packet¬ 
switching  networks.  The  high  throughput  and  low  delay  is  accomplished 
by  stripping  some  of  the  protocol  processing  out  of  the  service.  FPS  does 
not  provide  any  network  link-to-link  error  or  flow  control.  Due  to  the 
high  speeds  at  which  information  is  delivered  using  FPS,  it  is  more 
efficient  to  allow  the  network  layer  at  the  DTE  to  request  a  re¬ 
transmission,  rather  than  check  each  message  at  eveiy  link. 

The  two  basic  types  of  FPS  include  “frame  relay"  and  “cell 
relay.”  The  basic  difference  between  the  two  is  the  length  of  the  packet. 
The  frame  relay  allows  for  variable  length  packets  while  cell  relay 
standardizes  the  packet  (in  this  case  called  a  “cell”)  length  at  53  bytes. 

By  using  a  standardized  cell  size,  cell  relay  can  implement  hardware- 
based  switching.  Hardware-based  svdtching  can  occur  much  faster  than 
software-based  switching.  Because  of  the  variable  frame  size,  frame-relay 
must  use  software-based  switching.  Frame  relay  can  provide  service  up 
to  1.5  Mbps,  while  cell  relay  can  provide  up  to  a  minimum  of  2.5  Gbps. 
However,  due  to  the  small  48-byte  data  package  contained  in  each  cell, 
cell  relay  has  a  much  higher  overhead  (-10%)  compared  to  frame  relay 
(-0.33%  -  4%). 

“As  a  general  rule,  the  lower  the  speed  (e.g.,  T1  and  sub  Tl),  the  more 
concerned  you  are  with  overhead  for  data  applications...At  levels  of  T3  and 
above,  the  benefits  of  ATM  outweigh  the  efficiency  considerations.  At 
relatively  lower  speeds  (  Tl  and  below),  frame  relay  more  efficiently  transports 
data.”  [Ref  17] 
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c.  The  X.25  Protocol 

We  will  use  the  X.25  protocol  to  show  how  network  layer 
protocols  are  made  up  of  sub-protocols  to  interact  with  the  underlying 
layers.  The  X.25  protocol  is  a  connectionless,  virtual  circuit,  packet¬ 
switching  protocol. 

At  the  network  layer  (layer  3),  X.25  consists  of  the  X.25 
Packet  Layer  Protocol  (PLP).  The  X.25  PLP  defines  the  necessary  packet 
formats,  such  as  the  data  and  control  packets.  It  also  defines: 

1 .  what  control  packets  are  exchanged  in  order  to  establish  or 
disconnect  a  virtual  circuit; 

2.  a  sliding  window  for  error  and  flow  control. 

At  the  datalink  layer  (layer  2),  X.25  consists  of  the  LAP-B 
(Link  Access  Protocol;  a  subset  of  HDLC)  protocol.  This  layer  provides 
the  link-to-link  error  6&  flow  control  for  the  virtual  circuit.  At  the  physical 
layer  (layer  1),  X.25  consists  of  the  X.21  layer  1  protocol  (or  EIA-232-D). 
We  covered  this  protocol  back  in  section  B-3. 

8.  Transport  Layer 

The  transport  layer  provides  error  control  at  the  network  level.  It 
also  consists  of  connection-oriented  and  connectionless  services. 

a.  “Connection-Oriented”  VS.  “Connectionless”  Service 

Connection-oriented  transport  services  establish,  maintain, 
and  terminate  the  logical  connections  between  transport  users.  They 
also  ensure  reliable  end-to-end  sequenced  delivery  and  error  8s  flow 
control. 

The  ISO  transport  protocol  for  connection-oriented  is  known 
as  “ISO  TP  (or  ISO  8073).”  There  are  five  different  classes  of  TP  available, 
each  providing  different  levels  of  error  control.  They  are  as  follows: 

1 .  class  4  (TP4)  error  detection  8s  recovery; 
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2.  class  3  (TPS); 

3.  class  2  (TP2); 

4.  class  1  (TPl)  basic  error  recovery; 

5.  class  0  (TPO)  simple  class. 

ISO  TP-4  is  functionally  identical  to  the  DOD  TCP  standard. 

The  connectionless  protocol  is  “ISO  8062.”  This  protocol  is 
used  by  applications  that  favor  speedy  handling  over  reliability;  they  do 
not  need  reliable  transmission  of  messages.  ISO  8062  corresponds  to 
the  DOD  UDP  standard. 

9.  Conclusion 

In  this  section,  we  have  reviewed  some  of  the  basics  of 
communications  to  assist  the  design  team  in  understanding  the  origin 
and  purpose  of  various  protocols.  It  is  hoped  that  this  section  will  be  a 
useful  reference. 

C.  MICROWAVE  SYSTEMS 

In  a  microwave  system,  the  transmitting  and  receiving  equipment 
must  be  designed  for  the  frequency  selected,  for  the  given  transmission, 
and  for  the  bandwidth  required  [Ref.  14], 
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A  microwave  system  consists  of  end  sites  and  relay  sites,  as 
illustrated  in  Figure  17.  A  simplified  illustration  of  a  typical  relay 
station,  as  part  of  the  transmission  channel,  can  be  seen  in  Figure  18. 


Figure  1 7:  Microwave  Relay  Block  Diagram 

The  basic  function  of  the  relay  link  is  to  receive  the  wave  from  the 
preceding  station,  amplify  it  by  the  desired  amount,  and  radiate  it  toward 
the  next  station. 
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Figure  1 8:  Simplified  Microwave  Relay  Component  Diagram 


A  microwave  site,  of  course,  is  not  as  simple  as  these  diagrams 
portray.  The  system  design  will  have  to  consider  an  interplay  among  a 
number  of  factors  The  following  are  some  examples  : 

1 .  In  selecting  a  carrier  frequency,  the  higher  this  frequency,  the 
greater  the  bandwidth  that  can  be  obtained  for  the  channel  and 
the  smaller  the  antennas  for  a  given  antenna  gain.  However, 
the  efficiency  and  reliability  of  available  amplifiers  is  lower.  At 
too  high  a  frequency,  atmospheric  and  rain  attenuation  may 
also  occur  along  the  propagation  path. 

2.  The  larger  the  antennas  for  a  selected  carrier  frequency,  the 
greater  the  antenna  gain.  This  permits  either  lower 
amplification  at  each  station  or  a  greater  station  spacing  for  a 
given  amplifier.  However,  large  antennas  with  a  large  wind 
loading  increase  the  cost  of  each  station;  thus  these  advantages 
and  disadvantages  must  be  balanced. 

3.  The  use  of  tall  towers  or  selection  of  station  locations  on  high 
mountains  offers  the  best  propagation  possibilities.  This  may 
permit  greater  station  spacing  or  less  expensive  repeater  design. 
However,  it  may  increase  the  cost  of  construction  or 
maintenance  of  the  station. 
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4.  Using  wide  bandwidth  channels  permits  greater  signal 
multiplexing  or  lower  signal-to-noise  ratios,  hence  greater 
station  spacing,  up  to  a  certain  point.  The  design  of  very 
broadband  amplifiers  and  other  components  becomes 
expensive,  and  noise  figure  may  decrease  the  signal  strength 
faster  than  the  bandwidth  improves  it.  Thus,  a  parallel  link  may 
be  a  better  solution  for  increasing  channel  capacity  beyond  a 
certain  point. 

In  the  design  problem,  interrelations  among  transmitted  frequency, 
antenna  size,  transmitted  power,  receiver  noise  figure,  and 
characteristics  of  the  propagation  path  are  again  important.  Pulse  width 
and  repetition  rate  offer  two  additional  variables  to  the  equation. 

One  of  the  alternatives  for  BAGS  is  the  use  of  higher  frequency 
digital  microwave  system.  For  this  purpose,  a  number  of  factors  must  be 
examined  to  understand  the  affects  of  a  higher  frequency. 

From  a  general  standpoint,  the  design  of  a  general  microwave  link 
requires  performing  an  iterative  sequence  of  the  following  steps  : 

1 .  Path  and  site  selection; 

2.  Propagation  and  interference; 

3.  Selection  of  equipment  capable  of  satisfying  the  availability 
objectives  set  for  the  route; 

4.  Final  calculations. 

The  microwave  beam  behaves  much  like  a  light  beam  as  far  as 
atmospheric  influences  are  concerned.  It  is  also  subject  to  other  external 
influences  as  described  in  the  following  discussion. 

1.  Influence  of  Terrain  and  Obstructions 

The  microwave  beam  is  influenced  by  the  intermediate  terrain 
between  stations  and  by  obstacles.  It  tends  to  follow  a  straight  line  in 
azimuth  unless  intercepted  by  structures  in  or  near  the  path.  In  traveling 
through  the  atmosphere  it  usually  follows  a  slightly  curved  path  in  the 
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vertical  plane,  i.e.,  it  is  refracted  vertically  due  to  the  variation  with 
height  in  the  dielectric  constant  of  the  atmosphere.  Generally,  this 
refraction  is  slightly  downward,  so  that  the  radio  horizon  is  effectively 
extended.  The  amount  of  this  refraction  varies  with  time  due  to  changes 
in  temperature,  pressure,  and  relative  humidity.  These  control  the 
atmospheres  dielectric  constant. 

The  beam  can  be  reflected  from  relatively  smooth  terrain  and  water 
surfaces,  just  as  a  light  beam  is  reflected  by  a  mirror.  This  occurs 
mainly  at  small  angles  of  incidence.  A  good  illustration  of  this  can  be 
seen  in  the  case  of  an  asphalt  highway.  When  viewed  directly,  the  surface 
looks  slightly  rough  and  does  not  reflect  light  well;  however,  when  viewed 
from  a  distance  at  a  very  small  angle,  it  looks  like  a  mirror  or  wet 
surface. 

An  important  concept  in  analyzing  microwave  propagation  effects, 
particularly  those  of  diffraction,  refraction,  reflection,  and  the  effects  of 
terrain  and  obstructions,  is  that  of  the  Fresnel  zone.  The  first  Fresnel 
zone  radius  is  a  kind  of  "rubber"  unit,  which  is  used  to  measure  certain 
distances  (path  clearances  in  particular)  in  terms  of  their  effect  at  the 
frequency  in  question,  rather  than  in  terms  of  feet.  The  second  and 
higher  order  Fresnel  zones  are  also  very  important  under  certain 
conditions,  such  as  highly  reflective  paths. 

Although  a  microwave  beam  is  conventionally  shown  as  a  line,  the 
actual  method  of  propagation  is  as  a  wave  front,  and  the  important 
portion  of  the  wavefront  involves  a  sizable  transverse  area. 

In  order  to  ensure  free  space  propagation,  it  is  essential  that  all 
potential  obstructions  along  a  path  are  removed  from  the  beam 
centerline  by  at  least  0.6  FI  ,  where  FI  is  the  radius  of  the  first  Fresnel 
zone  at  the  point  of  the  obstructions. 
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Because  refractive  bending  varies  in  cycles  daily  and  changes 
erratically  at  times,  the  clearance  over  the  intermediate  terrain  must  be 
adjusted  to  minimize  the  losses  during  extreme  bending  conditions.  This 
calls  for  a  path  clearance  over  immediate  objects  somewhat  greater  than 
line-of-sight.  Normally,  the  beam  is  bent  downward  by  atmospheric 
refraction.  Though,  at  times,  the  atmospheric  conditions  may  be  such 
that  the  beam  is  bent  upward,  effectively  reducing  the  clearance  over 
terrain  in  the  path. 

2.  Fading 

Fading  is  a  general  term  applied  to  loss  of  signal  as  seen  by  the 
radio  receiver  at  its  input.  The  term  is  intended  to  apply  to  propagation 
variables  in  the  actual  radio  path. 

The  actual  fading  is  the  change  in  path  loss  between  the 
transmitter  at  one  station  and  its  receiver  at  the  following  station.  These 
changes  in  path  loss  have  to  do  with  atmospheric  conditions  and  the 
geometry  of  the  path. 

The  effect  of  fading  on  radio  paths  is  much  greater  than  the 
attenuation  variables  of  open  wire  and  cable  carrier  systems,  which  are 
primarily  due  to  the  effect  of  temperature  variations  in  the  metallic 
medium.  Radio  fading  is  caused  by  refractive,  diffractive,  and  reflective 
effects  in  connection  with  the  atmosphere  and  fixed  objects.  Fading  can 
result  in  defocusing,  blocking,  and  sometimes  cancellation  from  multiple 
paths  of  varied  lengths,  due  to  the  resultant  variation  in  phase  angles  on 
arrival  at  the  receiving  antenna. 

Although  the  atmosphere  and  terrain  over  which  a  radio  beam 
travels  have  a  modifying  effect  on  the  loss  in  a  radio  path,  there  is,  for  a 
given  frequency  and  distance,  a  characteristic  loss.  This  loss  which  is 
known  as  the  free  space  loss  increases  with  both  distance  and  frequency. 
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The  source  of  greatest  loss  in  a  typical  radio  transmission  path  is  free- 
space  loss  (FSL)  resulting  from  the  propagation  of  the  transmitted  signal  of 
frequency  (Fmhz)  over  the  distance  (D)  in  statute  miles  between  EIRP  and 
receiving  antennae. [ref.  18,  p.  11]. 

Changing  from  2Ghz  to  8Ghz  can  have  a  great  affect  on  the  FSL. 
For  example,  the  existing  microwave 
shot  from  Monterey  to  Mount 
Umunhum  is  38.06  miles.  As  we  can 
see  in  Table  9,  the  average  loss  from 
changing  to  8GHz  is  12.1  dB.  [Ref. 

18,  p.  11] 

This  loss,  in  addition  to  the 
other  variables,  indicates  the  current  site  locations  within  the  BAGS 
system  must  be  re-evaluated  for  operation  at  the  higher  frequency. 

3.  Atmospheric  Effects 

For  frequencies  below  about  100  GHz,  attenuation  caused  by 
snow,  hail  and  fog  can  generally  be  expected  to  be  significantly  less  than 
rainfall  attenuation  for  most  regions  of  the  earth.  Under  this 
circumstance,  design  considerations  for  fading  margins  required  for 
precipitation  attenuation  can  be  based  on  rainfall  statistics  alone  [Ref. 
19]. 

Attenuation  of  microwave  signal  due  to  rainfall  along  the  path  is 
present  to  some  degree  at  all  microwave  frequencies.  At  higher 
frequencies  the  excess  attenuation  due  to  rain  increases  rather  rapidly 
and,  in  the  bands  above  about  10  GHz,  is  great  enough  to  significantly 
affect  path  length  criteria,  except  in  areas  of  very  light  precipitation 
[Ref.  20]  . 

The  degree  of  attenuation  is  a  function  of  a  number  of  variables 
including  the  frequency  band,  size  and  shape  of  the  drops,  and  the 
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distribution  of  rain  (in  terms  of  its  instantaneous  intensity)  along  the 
path.  What  is  important  is  not  the  total  amount  of  rain  which  falls  over 
an  extended  period,  but  rather  the  maximum  instantaneous  intensity  of 
fall  which  is  reached  at  any  given  moment,  and  the  size  of  the  area  over 
which  the  high  intensity  cell  extends  at  that  moment. 

The  San  Francisco  Bay  Area  average  monthly  rainfall  statistics  is 
given  in  Table  10“^.  This  figure  reveals  that  the  rainfall  is  quite  intense 
during  the  winter  season. 


Average  Monthly  Rainfall 


San  Francisco  Bay  Area 


Jii  Aug  Sep  Oct  Nov  Dec  Jan  Feb  Mar  Apr  May  Jun 


Month 


Table  1 0:  Average  Monthly  Rainfall  in  San  Francisco  Area 


*  Courtesy  of  the  San  Francisco  Weather  Forecasting  Service. 
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Two  things  to  bear  in  mind  in  connection  with  rain  attenuation 
are:  (1)  multipath  fading  does  not  occur  during  periods  of  heavy  rainfall, 
so  the  entire  path  fade  margin  is  available  to  combat  the  rain 
attenuation,  and  (2)  neither  space  diversity  nor  in-band  frequency 
diversity  provide  any  improvement  against  rain  attenuation. 

In  practice,  signal  attenuation  due  to  fog  is  usually  modest 
compared  with  the  attenuation  rates  for  rain.  On  rare  occasions,  the 
liquid-water  content  can  become  as  high  as  0,5  to  1.0  g/m^  in  veiy 
dense  radiation  fogs.  Such  fogs  can  be  expected  to  produce  attenuation 
rates  comparable  to  those  caused  by  rain 

Fog  which  occurs  very  close  to  the  ground  in  the  early  morning,  * 
usually  in  a  valley  immediately  over  a  small  stream,  has  quite  another 
effect.  In  this  case,  the  normal  beam  is  in  the  clear,  but  the  surface  at 
the  fog  layer  is  a  smooth  strata  which  forms  a  good  reflector  of 
microwave  energy  [Ref.  19]  . 

4.  Site  Selection 

Terminal  sites  are  normally  located  at  enterprise  facilities. 

However,  the  relay  sites  are  located  with  emphasis  on  propagation  over 
the  intermediate  paths,  and  possible  interference  from  internal  or 
external  sources. 

The  choice  of  relay  sites  is  greatly  influenced  by  the  nature  of  the 
terrain  between  sites.  In  preliminary  planning  it  may  be  assumed  that,  in 
relatively  flat  areas,  the  path  lengths  will  average  between  25  and  35 
miles  for  the  frequency  bands  from  2-8  GHz.  Distances  greater  than  35 
miles  between  two  sites  may  cause  system  degradation. 
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5.  Equipment 

The  characteristics  of  the  microwave  system  components  to  be 
used  affect  the  engineering  choices  and  path  performance  parameters. 
Thus,  the  survey  engineers  must  know  in  advance: 

1.  frequency  bands  to  be  used; 

2.  type  of  service  (analog/ digital); 

3.  number  of  channels  (both  present  and  future); 

4.  performance  and  reliability  criteria  desired; 

5.  parameters  of  the  microwave  equipment  to  be  used  (i.e., 
transmitter  output  power,  receiver  noise  figure,  bandwidth, 
etc.). 

Primary  considerations  during  the  selection  of  the  microwave  radio 
equipment  include: 

1 .  Characteristic  of  the  end-to-end  baseband  facility,  including 
bandwidth,  frequency  response,  loading  capability,  noise  figure, 
and  noise  performance; 

2.  The  amount  of  radio  gain  available,  as  determined  by 
transmitter  power  output  and  receiver  noise  characteristic; 

3.  Operating  frequency  band,  and  required  frequency  spacing 
between  radio  channels,  as  determined  by  transmitter 
deviation,  receiver  selectivity,  and  frequency  stability; 

4.  Primary  power  requirements  and  options  available; 

5.  Supervisory  functions  available,  including  order  wire,  alarms, 
and  controls; 

6.  Equipment  reliability,  including  availability  of  redundant 
versions  such  as  frequency  diversity,  1-for-N  or  2-for-N  multi- 
line  switching,  hot  standby,  or  hot  standby  at  transmitter  and 
space  diversity  at  receivers; 

7.  Provisions  for  testing  and  maintenance. 

Towers  have  a  significant  effect  on  many  microwave  path 
engineering  choices.  Prior  knowledge  of  the  tower  limitations  is  critical. 
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These  include  wind,  ,  weight,  and  height  limitations  to  name  a  few.  The 
type  of  waveguide  and  transmission  lines  to  be  used  is  important,  not 
only  for  their  loss  characteristics,  but  also  for  the  degree  of  impedance 
matching  attainable.  This  effects  the  echo  distortion  noise. 
Transmission  line  characteristics  become  extremely  important  with  high 
density  systems  having  long  waveguide  runs. 

The  type  and  the  size  of  the  antenna  that  will  be  used  depends  on 
several  variables.  The  most  important  ones  are  the  gain,  the  area  of 
antenna  aperture,  and  the  wavelength  at  operating  frequency.  The 
existing  tower  must  also  be  considered. 

6.  Propagation  and  Interference 

The  final  objective  for  any  microwave  system  is  to  provide  the  most 
cost-efficient,  distortion-free,  and  interference-free  service  continuity  for 
the  type  of  service  assigned.  Overall  reliability,  or  service  continuity, 
involves  not  only  equipment  failure  rates  and  power  failures,  but  also  the 
propagation  performance  of  the  individual  paths.  This  involves  antenna 
sizes  and  elevation,  frequency  or  space  sepajations  in  diversity  systems, 
path  lengths,  and  frequency  attenuation  relationships.  It  also  includes 
fading  margins  which,  in  addition  to  path  parameters,  are  affected  by 
noise  figure,  transmitter  power,  and  attenuation  of  waveguide,  and  filter 
arrangements. 

Distortion  may  occur  in  the  radio  path,  but  more  often  it  occurs 
due  to  poor  return  loss  of  amplifier  components,  waveguide  filters,  and 
antennas.  Also  the  characteristic  of  switching  devices  and/or  combiner’s 
are  involved  [Ref.  21]. 
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D.  SATELLITE 

The  satellites  can  be  classified  as  "geostationary"  or  "low  orbit" 
depending  on  their  distance  to  the  earth.  The  distance  of  geostationary 
satellites  to  earth  turns  out  to  be  a  disadvantage  because  of  propagation 
delay.  This  delay  is  caused  by  the  information  traveling  a  minimum  of 
45,000  miles  before  the  data  is  received  by  the  user  facility.  Large  block 
sizes  are  used  to  improve  efficiency.  However,  due  to  the  delays 
encountered,  recovery  of  errors  in  blocks  of  information  becomes  time 
consuming  and  costly.  Therefore,  the  geostationary  satellites  are  not 
suitable  for  applications  that  require  very  short  response  times.  [Ref.  22] 

As  an  answer  to  this  problem,  several  consortiums  have  planned 
extensive  low-altitude,  thus  non-geostationary,  satellite  communications 
systems.  These  low-altitude  orbits  have  a  much  shorter  propagation 
delay,  which  is  necessaiy  for  real-time  duplex  communication.  These 
orbits  also  provide  small  propagation  loss,  allowing  the  use  of  low  power 
and  smaller  satellites  and  earth  station  antennae. 

Most  vendors  offer  three  types  of  service:  l)channel-based,  2) 
carrier-based,  or  3)  leased  services.  Individual  channels  foir  services  less 
than  T-1  may  be  leased  while  wideband  applications  are  normally 
purchased. 

The  author  has  found  two  existing  commercial  satellite  systems 
(Inmarsat  and  AMSC)  and  three  other  systems  that  are  in  various  stages 
of  development.  Since  Inmarsat  has  been  operating  since  1982,  we  will 
discuss  it  in  some  detail.  We  will  then  briefly  discuss  the  other  four 
systems. 

1.  The  Inmarsat  System 

Inmarsat  is  an  international  organization  operating  the  only  global 
satellite  system  for  mobile  communications.  The  organization  was 
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established  in  1979,  mainly  on  the  initiative  of  the  International 
Maritime  Organization  (IMO),  with  an  initial  mandate  from  its 
communications  system  to  serve  the  maritime  community  by  improving 
communications  and  the  radio-navigation  for  safety  of  life  at  sea  and 
efficient  ship  management. 

By  convention,  the  Inmarsat  space  segment  is  open  for  peaceful, 
non-discriminatory  uses  by  all  nations,  whether  members  of  Inmarsat  or 
not.  The  organization  is  required  to  provide  services  in  all  geographical 
areas  where  there  is  a  need  for  mobile  communications  .  Coverage  now 
exists  over  the  whole  globe  except  the  extreme  polar  regions. 

From  Inmarsat’s  point  of  view,  it  is  role  is  clearly  divided  into  two 
main  areas: 

1 .  providing  the  space  segment  for  instant  reliable  distress  and 
safety; 

2.  a  general  satellite  communications  for  the  maritime  community. 

Inmarsat  has  two  major  satellite  communications  systems 
designed  to  provide  most  of  the  medium  and  long  range  communications 
functions:  Inmarsat-A  and  Inmarsat-C.  Inmarsat  also  offers  Inmarsat-E, 
and  1-band  EPIRB  system. 

The  Inmarsat  system,  like  most  satellite-based  commixnications 
systems,  is  comprised  of  three  segments: 

1 .  the  space  segment; 

2.  the  ground  control  facilities; 

3.  the  end-user’s  Mobile  Earth  Station  (MES),  also  known  as  Ship 
Earth  Stations  (SES)  in  the  maritime  environment. 

a.  Space  Segment: 

The  space  segment  is  planned,  procured,  maintained,  and 
operated  by  Inmarsat,  and  financed  by  the  Inmarsat  Signatories. 
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Inmarsat  started  commercial  operations  in  February  1982  with  leased 
satellite  capacity  from  Comsat  General,  Intelsat  and  the  European  Space 
Agency  (ESA). 

In  1982,  Inmarsat  launched  its  own  satellite  system 
composed  of  four  satellites  built  by  British  Aerospace  and  Hughes 
Aircraft.  Each  of  these  new  satellites  has  a  total  L-band  EIRP  of  39  dBw 
transmitted  though  a  single  global  beam  enough  to  support  more  than 
250  Inmarsat-A  type  channels.  Each  satellite  was  designed  for  a  ten- 
year  life  mission  in  orbit  and  should  be  available  for  service  well  beyond 
the  year  2000. 

In  1991,  Inmarsat  signed  a  contract  with  a  consortium  led 
by  GE  Astro  and  Marconi  Space  Systems  to  procure  a  first  batch  of  four, 
third-generation  satellites  (Inmarsat-3).  These  represented  the  most 
technologically  advanced  mobile  satellite  developed  at  the  time.  Each 
Inmarsat-3  satellite  has  eight  times  the  L-band  power  of  an  Inmarsat-2 
satellite  (i.e.,  48  dBw  compared  39  dBw).  In  addition  to  global  beam 
coverage,  each  Inmarsat-3  satellite  provides  coverage  to  four  or  five 
transmit-and-receive  spot  beams  at  L-band.  The  first  of  these  satellites 
was  scheduled  for  delivery  in  late  1994. 

b.  Land  Earth  Stations: 

A  worldwide  network  of  gateway  Land  Earth  Stations  (LES), 
or  Coast  Earth  Stations  (CES)  for  maritime  purposes,  provide  links  for 
the  end  user,  through  the  satellites,  to  the  terrestrial  pubUc  switched 
telecommunications  network.  LES  are  owned  and  operated  by 
telecommunications  authorities,  mostly  Inmarsat  Signatories,  which 
provide  the  mobile  services  to  the  end  users. 
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c.  Mobile  Earth  Stations: 

The  Mobile  Earth  Station  (MES),  Known  as  Ship  Earth 
Stations  (SES)  in  the  maritime  environment,  are  obtained  from  a  number 
of  manufactures  and  are  commissioned  by  Inmarsat  to  utilize  the 
system. 

At  present,  there  are  two  families  of  Inmarsat  satellite 
communications  equipment  available  to  mariners.  Inmarsat-A  is  the 
larger  and  more  versatile,  offering  voice,  data,  facsimile  and  telex-based 
communications.  Inmarsat-C  terminals  are  smaller  and  offer  text  and 
data  messaging  at  lower  speeds. 

2.  American  Mobile  Satellite  Corporation  (AMSC) 

The  AMSC  was  established  in  1988  and  has  been  licensed  by  the 
Federal  Communications  Commission  to  provide  mobile  satellite  services. 
As  Figure  19  shows,  AMSC  coverage  includes  most  all  of  North  America, 
extending  approximately  200  miles  out  to  sea. 

AMSC  services  are  provided  through  one  satellite  in 
geosynchronous  orbit  22,300  miles  above  the  equator  at  101°  West 
Longitude.  AMSC  also  has  an  agreement  with  a  sister  Canadian 
company  for  backup  satellite  coverage,  in  case  of  failure.  The  satellite 
uses  six  spot  beams  and  30  MHz  of  L-band  spectrum  to  provide 
transmission  coverage.  Using  the  Ku-band,  the  satellite  can  receive 
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Figure  1 9:  AMSC  Maritime  Standard  Coverage  Area 


private  network  transmissions  from  anywhere  in  North  America.  This 
band  is  also  used  for  the  satellite  uplink  gateway  located  14  miles  from 
Reston,  VA.  A  diversity  uplink  site  is  provided  under  an  agreement  with 
Washington  International  Teleport.  The  two  site  are  connected  by  a  full¬ 
time  analog  fiber  optic  circuit  leased  from  Bell  Atlantic.  [Ref.  23] 

AMSC  will  offer  voice,  fax,  and  switched  data  services  in  the 
following  four  areas: 

1 .  satellite  telephone  service:  consists  of  satellite-only  telephone 
service; 

2.  satellite  roaming  service:  extends  cellular  services  to  all 
coverage  areas.  Subscribers  place  calls  via  cellular  network 
when  traveling  in  cellular  coverage  area.  Outside  of  coverage 
area,  calls  are  processed  via  satellite  [Ref.  24,  p.  6]  ; 

3.  fleet  management  services:  in  addition  to  above  mentioned 
services,  fleet  management  provides  nationwide  voice  dispatch 
and  position  location  services.  These  services  are  available  to 
maritime,  ground  vehicles,  aviation,  and  fixed  sites. 

4.  private  network  capacity:  offers  satellite  capacity,  switched 
service  and  network  management  to  private  network 
customers.. 

3.  Prospective  Satellite  Projects 
a.  The  Iridium  System: 

A  consortium  led  by  Motorola  plans  to  launch  66  low-earth 
orbiting  satellites  as  part  of  it  is  $3.4  billion  Iridium  effort;  it  is  expected 
to  provide  2.4  kilobit/ sec  data  transmission  to  mobile  users.  [Ref.  25,  p. 
S36] 


b.  Teiedesic  System: 

A  consortium  led  by  Microsoft  and  McCaw  Cellular  plans  to 
launch  840  low-orbit  satellites  delivering  voice,  data,  and  video  services 
at  speeds  up  to  16  kilobit/ sec.  [Ref.  25,  p.  S36] 
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c.  GlobalStar  System: 

Supported  by  Loral  Corp.,  Qualcomm  Inc.,  and  PacTel  Corp., 
Globalstar  plans  on  launching  48  low-orbit  satellites  in  1998.  At  a  cost 
of  $275  million,  they  plan  to  offer  data  transmissions  at  9.6  kilobit/ sec. 
[Ref.  25,  p.S36] 

E.  WIRELESS  TECHNOLOGY 

A  wireless  network  providing  alternative  routing  for  the  VHF 
National  Distress  System  would  provide  the  required  duplexing  features 
and  could  be  an  innovative  approach.  A  standby  cellular  and  satellite 
alternative  routing  system,  such  as  the  one  illustrated  in  Figure  20,  has 
been  proposed  by  the  American  Mobile  Satellite  Corporation  for 
alternative  routing.  In  the  event  of  leased-line  failure,  switching 
equipment  would  attempt  to  re-establish  the  VHF  NDS  link  via  the 
cellular  network.  If  this  link  could  not  be  established,  the  switching 
equipment  would  then  re-establish  the  link  using  the  AMSC  satellite. 

Corporate  owned  cellular  telephone  systems  operating  in  the  San 
Francisco  area  theoretically  encompass  all  the  CG  facilities  in  the  area. 
Figure  2 1  shows  the  San  Francisco  Bay  area  coverage  for  Cellular  One 
Inc..  This  existing  cellular  system  has  numerous  overlapping  cells  with 
emergency  power  services  immediately  available.  Information  concerning 
the  actual  operational  availability  of  the  individual  cellular  companies  is 
treated  as  “corporate  secrets”;  they  are,  however,  considered  to  be  at 
least  99.5%  [Ref.  26,  p.  359]. 
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•e  1:  Standby  Cellular/Satellite  Alternative  Routing  Illustration 


A  wireless  telephone  network  could  be  quickly  expanded  during 
emergencies  to  facilitate  the  required  communications  between  CG 
command  centers  and  on-scene  commanders.  It  could  also  be  designed 
to  aid  in  the  relocation  of  command  resources  in  the  event  of  failures  or 
dxiring  an  emergency,  such  as  an  earthquake. 

Although  this  technology  has  never  been  used  by  the  CG  in  this 
manner,  the  alternative  deserves  to  be  fairly  evaluated. 

F.  CONCLUSION 

The  purpose  of  this  chapter  has  been  to  review  some  of  the  basic 
communication  services,  protocols,  and  technologies  available  today.  It 
is  intended  to  give  the  design  team  an  initial  understanding  of  the 
technology  that  is  available  today  and  where  technology  is  headed 
tomorrow. 

Although  developed  separately,  many  companies  have  developed 
interfacing  schemes  that  allow  various  standards  and  transmission 
media  to  be  integrated  into  a  single  WAN. 


Ill 
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VII.  SYSTEM  MIGRATION 


A.  INTRODUCTION 

This  chapter  covers  phases  five  and  six  of  the  Structured  Approach 
Model.  In  the  fifth  phase,  “Develop  Migration  Candidates,”  we  will 
discuss  the  factors  involved  when  developing  a  list  of  alternative 
migration  paths  that  can  be  used  to  reach  our  target  architecture.  In 
phase  VI,  “Select  Migration  Path,”  we  will  discuss  some  useful 
methodologies  to  help  us  determine  the  most  cost-effective  configuration 
from  the  list  of  alternatives  and  analyze  our  projects’  level  of  sensitivity  to 
change. 

In  the  previous  chapters  we  used  the  three  views  to  help  us 
visualize  aspects  of  the  project  we  may  have  otherwise  overlooked.  In  the 
author’s  opinion,  the  “organizational”  and  “functional”  views  during  these 
two  phases  mainly  serve  as  “checklist”  reminders.  This  reminds  us  to 
check  that  any  changes  to  business  processes,  and  that  all  functional 
requirements,  are  implemented  within  each  alternative.  On  the  other 
hand,  the  physical  view  begins  to  take  form  as  we  move  from  standards 
and  technical  capabilities  into  the  actual  details  of  alternative 
configurations.  Therefore,  our  discussion  of  these  two  chapters  will 
develop  around  the  required  tasks,  rather  than  the  views  being  used  at 
the  time. 
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B.  DEVELOP  MIGRATION  CANDIDATES 


1.  Limiting  the  Number  of  Migration  Paths  Considered 

There  are  a  number  of  factors  that  can  be  varied,  each  of  which 
could  affect  the  final  network  configuration.  Some  of  the  factors  that  can 
vary  between  possible  candidates  include: 

1.  the  level  of  functionality  attained  for  “should  have”  and  “nice  to 
have”  requirements  (this  goes  for  both  the  users  systems  and 
the  telecommunications  network); 

2.  the  timetable  for  implementing  the  various  technical 
capabilities; 

3.  the  technologies  used  for  implementation;  this  includes  the 
users  systems,  telecommunications  transmission  media,  and 
type  of  network  management  software  chosen. 

The  number  of  candidate  migration  paths  is  the  product  of  the 
following  equation: 


n 

^  Variations 

1 


Where, 

X  =  number  of  candidate  migration  paths 
Fn  =  number  of  factors 

Variations  =  number  of  variations  for  each  factor 


Equation  1:  Migration  Path  Alternatives  Calculation 


Each  time  a  factor  variation  is  added,  the  number  of  new  candidate 
paths  increases  by  a  whole  magnitude.  Therefore,  we  must  find  ways  to 
limit  these  variations.  Dr.  Emery  states: 
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Since  each  alternative  examined  entails  a  certain  amount  of  effort,  the 
number  must  be  limited  to  three  or  four  substantially  different  alternatives.  It  is 
important,  though,  that  they  encompass  a  wide  range  of  characteristics  so  that 
attractive  options  will  not  be  overlooked. 

At  the  low  end  of  the  range,  a  bare  minimum  design  should  aim  only  at 
satisfying  the  “must  have”  user  needs  (with  perhaps  some  of  the  more  cost- 
effective  “should  haves”  thrown  in  for  good  measure).  A  high-end  system 
should  meet  most  of  the  “should  have”  and  many  of  the  “nice  to  have” 
requirements.  This  wide  range  is  quite  likely  to  bracket  the  design  that  provides 
the  best  balance  between  cost  and  benefits.  [Ref.  27,  p.  232] 

Although  any  limitation  increases  the  risk  of  overlooking  the  one 
optimal  candidate  path,  by  using  common-sense  and  deliberation  to 
make  and  apply  assumptions,  the  design  team  should  be  able  minimize 
both  the  factor  variations  and  this  associated  risk.  All  assumptions 
made,  including  factors  leading  to  the  assumptions,  should  be  recorded 
in  the  project  folder.  If  there  are  no  communicable  reasons  for  reaching 
an  assumption,  record  this  fact.  There  is  nothing  wrong  with  this,  as 
long  as  a  consensus  is  reached.  What  is  important  is  collecting  and 
tracking  the  thought  process  behind  the  decisions;  this  is  for  team- 
learning,  not  for  criticism. 

Some  methods  suggested  for  limiting  the  number  of  factor 
variations  include: 

1.  Limit  Functional  Requirement  Variations:  As  suggested  by 
Dr.  Emeiy,  above,  the  design  team  can  begin  by  agreeing  to  two 
designs,  one  that  lies  at  the  low  end  of  the  functional  scale,  one 
at  the  high  end.  Once  the  cost-effectiveness  analysis  has  been 
completed  using  these  two  designs,  the  design  team  can 
compare  the  additional  benefits  gained  from  the  high-end 
configuration  to  the  incremental  costs  between  the  two 
configurations.  Depending  on  the  outcome  of  the  comparison, 
management  can  decide  if  the  marginal  return  on  the  additional 
expenditure  is  equal  to,  or  greater  than,  the  marginal  return  of 
the  best  use  of  the  additional  resources. 

2.  Limit  Timetable  Variations:  The  design  team  can  agree  to  one 
initial  timetable  for  implementing  the  various  technical 
capabilities.  Once  a  final  configuration  is  agreed  upon,  the 
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implementation  timetable  can  be  re-evaluated  to  take  advantage 
of  any  efficiencies  offered  by  that  particular  configuration. 

3.  Limit  Technology  Variations:  A  standards-based  target 
architecture  was  developed  in  Chapter  5.  The  design  team 
must  choose  a  transmission  media  (including  the  component 
configuration  to  implement  it)  and  a  network  management 
system  that  provides  the  optimal  migration  path  to  reach  the 
target  architecture.  The  available  alternatives  for  each  of  these 
will  be  ranked  later  in  this  chapter  using  FOM.  However, 
certain  alternatives  may  be  ruled  out  early  using  known 
limitations,  or  initial  cost  data.  Using  the  BAGS  as  an  example, 
we  know  that  analog  microwave  will  not  meet  our  set 
requirements  as  a  transmission  media.  With  minimal  research 
effort,  some  available  network  management  applications  may  be 
ruled  out,  due  to  costs  or  for  lack  of  required  network 
troubleshooting  features. 

2.  Specific  Site  Alternative  Limitations 

The  physical  sites  involved  in  most  telecommunications  projects 
vaiy  greatly.  Some  of  these  variations  will  limit  the  technical  alternatives 
available  at  particular  sites.  For  instance,  suppose  that  cellular  links  are 
being  considered  as  a  major  contender  for  system  redundancy.  However, 
we  assume  (or  know)  that  cellular  capability  is  not  available  at  10%  of 
the  sites.  Rather  than  throwing  this  in  as  another  variation,  it  would 
simplify  the  process  if  we  complete  the  cost-effectiveness  analysis  before 
considering  these  specific  variations.  Once  the  cost-effectiveness 
analysis  has  ranked  our  technical  alternatives,  and  cellular  has  been 
chosen,  we  can  consider  altering  our  plans  for  specific  sites  to  overcome 
any  limitations. 

Limitations  can  affect  scheduling,  such  as  weather  restricting  site 
access  to  given  times  of  the  year.  Other  site  limitations  could  include 
civil  engineering  aspects  (e.g.,  building  codes  and  restrictions,  space, 
power),  radio  spectrum  availability,  utility  access,  and  so  forth.  Unless 
these  restrictions  apply  to  a  large  percentage  of  the  sites,  they  should  be 
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considered  after  the  initial  cost-effectiveness  analysis.  The  design  team 
will  have  to  decide  the  percentage  of  sites  that  must  be  affected  before  a 
restriction  is  allowed  to  effect  the  configuration  used  for  the  initial  cost- 
effectiveness  analysis. 

C.  COST  EFFECTIVENESS  ANALYSIS 
1.  Introduction 

Many  of  the  concepts  presented  in  this  section  have  been  taken 
from  the  thesis  of  Cdr  Robert  Wilson  [Ref.  28,  Ch.  5-6]. 

The  purpose  of  performing  a  cost  effectiveness  analysis  (CEA)  is  to 
quantify  the  costs  and  effectiveness  of  network  alternatives  in  a  manner 
that  allows  the  alternative  with  the  best  overall  cost-effectiveness  to  be 
singled  out. 

Cost-effectiveness  relates  to  the  measure  of  a  system  in  terms  of 
mission  fulfillment  (system  effectiveness)...  True  cost-effectiveness  is 
impossible  to  measure  since  there  are  many  factors  that  influence  the  operation 
and  support  of  a  system  that  cannot  realistically  be  quantified  ...  thus,  it  is 
common  to  employ  specific  cost-effectiveness  figures  of  merit  (FOM)  ...  to 
allow  comparison  of  alternatives  on  the  basis  of  the  relative  merits  of  each.  [Ref. 

36,  p.  136] 

Detailed  definitions  for  costs  and  effectiveness  will  be  given  in  sections  4 
and  5. 

The  vast  majority  of  CG  telecommunications  projects  will  have 
program  costs  of  less  than  $30  million.  Therefore,  these  projects  will 
normally  be  categorized  as  “j  III”  (Ref.  29,  p.  2]  under  the  DOD  project 
definitions  and  “Level  IV”  under  the  DOT  project  definitions.  These 
project  definitions  allow  the  project  managers  to  choose  the  tools  they 
feel  are  best  to  implement  a  project  of  this  size. 
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Although  a  CEA  is  not  mandatory,  it  is  a  very  effective  tool  and  well 
worth  the  effort  required.  Application  of  CEA  techniques  assists  the 
decision  makers  in  quantifying  any  necessary  tradeoffs  and  permits: 

1 .  the  various  parties  to  a  decision  to  comprehend  the  basis  for 
each  other’s  conclusions; 

2.  decision  makers  to  draw  on  the  intuitions  and  judgments  of 
their  staffs  without  abdicating  their  decision  making 
prerogative; 

3.  sensitivity  analyses  to  be  made  using  variations  in  the 
estimates.  [Ref.  30] 

The  CG  COMDTINST  M4150.2D,  “Systems  Acquisitions  Manual,” 
can  be  a  great  asset  to  use  while  planning  and  implementing  even  the 
relatively  small  Level  IV  projects.  And  if  unexpected /uncontrollable 
problems  crop  up,  making  it  impossible  to  meet  schedule,  technical,  or 
cost  projections,  it  will  be  reassuring  to  any  project  manager  to  be  able  to 
demonstrate  every  effort  was  made  to  anticipate  problems  beforehand. 

2.  CEA  Overview 

Many  methods  exist  for  completing  a  CEA.  Some  methods  deal 
with  the  lack  of  tangible  benefits  better  than  others.  The  multi- attribute 
utility  method  used  here  was  chosen  because  it  measures  system 
effectiveness  without  having  to  estimate  monetary  values  for  the 
intangible  benefits  provided  by  the  system.  It  is  very  difficult  to  estimate 
intangible  benefits  for  military  telecommunications  networks  because  no 
market  value  can  be  affixed  to  the  final  product.  The  essential  steps  of  a 
CEA  include: 

1.  define  system  objective; 

2.  identify  essential  mission  requirements; 

3.  list  alternatives; 

4.  state  evaluation  assumptions; 
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5.  establish  effectiveness  measures; 

6.  evaluate  alternatives’  overall  effectiveness; 

7.  develop  cost  data; 

8.  assess  effectiveness  and  cost  risks; 

9.  perform  cost-effectiveness  computations; 

10. perform  sensitivity  analysis.  [Ref.  31,  32,  33] 

By  using  the  structured  approach  model,  the  first  three  steps  have 
already  been  accomplished.  The  next  seven  sections  will  deal  with  the 
remaining  steps. 

3.  State  Evaluation  Assumptions 

We  do  not  know  every  detail  of  the  actual  demands  that  will  be 
placed  on  a  telecommunications  system.  Therefore,  in  certain  areas  we 
must  make  assumptions  to  fill  in  the  missing  details.  For  instance,  do 
we  know  the  actual  availability  requirements  for  the  system?  Generally 
not,  but  we  can  assume  that  anything  less  than,  say,  99%  availability 
could  seriously  lower  our  mission  effectiveness.  An5where  that 
supporting  data  is  not  available  an  assumption  must  be  made.  However, 
assumptions  should  never  be  made  blindly;  the  attribute  should  be 
researched  and  the  assumption,  along  with  the  reasoning  behind  the 
conclusion,  should  be  documented. 

4.  Establish  Effectiveness  Measures 

To  establish  effectiveness  measures,  first  we  must  define 
effectiveness.  Hajek  defines  effectiveness  as; 

...a  measure  of  the  probability  that  the  equipment  will  be  ready  and 

capable  of  performing  its  fimction  and  will  not  experience  failure  during  its 

mission  period.  [Ref.  34,  p.  219] 
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The  functions  that  the  equipment,  or  in  our.  case  network,  is  to 
perform  have  been  spelled  out  in  the  requirements.  We  must  now  define 
what  we  mean  by  ready  and  capable.  These  are  defined  by  using  figures 
of  merit  (FOM),  also  referred  to  as  objectives  or  criterion.  For  clarity,  we 
will  stick  to  FOM. 


a.  Figures  of  Merit 

FOM  are  typically  broad  in  scope.  There  are  various 
techniques  for  generating  FOM.  Keeney  and  Raiffa  [Ref.  35,  p.  34] 
suggest  starting  at  the  overedl  objective  and  then  begin  asking  questions. 
For  instance,  our  overall  objective  for  a  telecommunications  network 
could  be  stated  as,  “our  objective  is  to  provide  a  telecommunications 
network  that  will  meet  the  users  requirements  and  expectations  in  the 
most  efficient  manner  possible.”  Now,  the  question  would  be,  “what 
characteristics  are  necessary  to  meet  our  objective?”  These 
characteristics,  or  FOM,  would  include  [Ref.  35  for  1-4]: 

1.  Reliability:  The  probability  that  a  system  or  product  will  perform 
in  a  satisfactory  manner  for  a  given  period  of  time  when  used 
under  specified  operating  conditions; 

2.  Maintainability:  The  ease,  accuracy,  safety,  and  economy  in  the 
performance  of  maintenance  actions; 

3.  Manability:  The  human  element  and  the  interface{s)  between  the 
human  and  machine; 

4.  Supportability:  The  composite  of  all  considerations  necessary  to 
assure  the  effective  and  economic  support  of  a  system 
throughout  its  programmed  life-cycle; 

5.  Interoperability:  The  communications  methods  between 
machines  that  provide  accurate  and  reliable  access, 
interconnection,  and  transmission  of  data  without  affecting  the 
applications  that  are  running.  [  Ref.  8,  vol.  4,  p.  F-9] 
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The  various  FOM  will  normally  influence  system 
effectiveness  at  different  levels.  To  compensate  for  this,  each  FOM  is 
weighted  to  equate  its  contribution. 

By  asking  the  question,  “what  do  we  mean  by  the  FOM?,”  the 
FOM  can  be  further  broken  down  into  more  specific,  measurable,  areas 
known  as  measures  of  performance  (MOP),  sometimes  referred  to  as 
attributes. 


b.  Measures  of  Performance 

A  MOP  should  be  both  comprehensive  and  measurable.  A 
MOP  is  comprehensive  if,  by  knowing  the  level  of  a  MOP  in  a  particular 
situation,  the  decision  maker  has  a  clear  understanding  of  the  extent 
that  the  associated  FOM  is  achieved.  A  MOP  is  measurable  if  it  is 
reasonable  both  (a)  to  obtain  a  probability  distribution  for  each 
alternative  over  the  possible  levels  of  the  MOP  -  or  in  extreme  cases  to 
assign  a  point  value  -  and  (b)  to  assess  the  decision  maker’s  preferences 
for  different  possible  levels  of  the  MOP.  For  example,  in  terms  of  a  utility 
function  or  in  some  circumstances,  a  rank  ordering.  [Ref.  35,  p.  39] 

Let’s  take  the  FOM  “maintainability”  as  an  example.  What  are  the 
characteristics?  Blanchard  and  Fabrycky  state  the  most  commonly  used 
maintainability  MOP  include: 

1.  Mean  corrective  maintenance  time  (also  known  as,  mean  time  to 
repair); 

2.  Mean  preventive  maintenance  time; 

3.  Median  active  corrective  maintenance  time; 

4.  Mean  active  maintenance  time; 

5.  Maximum  active  corrective  maintenance  time; 

6.  Logistics  delay  time; 

7.  Administrative  delay  time; 
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8.  Maintenance  downtime; 

9.  Mean  time  between  Maintenance; 

10.  Mean  time  between  replacement.  [Ref.  36,  p.  375] 

Notice  that  some  of  the  MOP  listed  above  overlap  (i.e.,  #4  = 
Average[#2  +  #3]).  The  final  set  of  MOP  chosen  for  each  FOM,  however, 
must  be  non-redundant.  Other  desirable  properties  of  the  final  set 
include  complete,  operational,  minimal,  decomposable  (for  definitions  see 
Ref.  35,  sec.  2.4.1]. 

Here  again,  the  various  MOP  will  normally  affect  the  FOM  at 
different  levels.  Therefore,  each  MOP  is  also  weighted  to  equate  its 
contribution  to  the  FOM. 

c.  Calculation  of  Overall  Effectiveness 

Now  that  the  FOM  and  MOP  have  been  defined  and  assigned 
weights,  overall  effectiveness  can  be  calculated.  Table  1 1  is  an  example 
summary  table  of  system  effectiveness.  Table  2  totals  FOM  values. 

FOM  values  and  effectiveness  are  calculated  using  the 
following  equations: 


Y^{MOPiUtility*MOPiWeight) 
FOMj  =  - 

Y^iMOPiWeight) 

1 


Equation  2:  Figure  of  Merit  Calculation 


'Z(FOM*FOMWeight) 
Effectiveness  =  ^ - 

^  (FOMi  Weight) 

1 


Equation  3:  Effectiveness  Calculation 
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Table  1 1:  MOP  Ratings  and  FOM  Expected  Values 


ACCURACY  MOP  Weight 


Uodate  Rate 


Reference  Sta.  2 


ACCURACY  Weighted:  Total 


AVAILABILITY  i  MOP  Weight 


10 


EMI  Resistance  3 


MP  85  Obs.  Res.  2 


5 


Graceful  Degrad.  I  5 


Alter.#  1 


5 


5 


5 


5 


Alter.#  1 


5 


5 


5 


5 


5 


AVAILABILITY  Weighted:  Total 


COVERAGE  MOP  Weight 


HHA/ Coastal  10 


Ocean  Phase  5 


5 


COVERAGE  Weighted:  Total 


INTEGRITY  MOP  Weight 


Timeliness 


Index  of  Safety  6 


INTEGRITY  Weighted:  Total 


ADAPTABILITY 


International 


Technical  Flex. 


Onen  Svs.  Int. 


Snectral  Eff. 


Institutional 


MOP  Weight 


3 


3 


6 


3 


6 


6 


Table  12:  Total  Weighted  FOM  Effectiveness  Example 


FOM 


ACCURACY  WTed 


AVAILABILITY  WTed 


COVERAGE  WTed 


INTEGRITY  WTed 


ADAPTABILITY  WTed  10 


OVE^IALL  WTed  Eflectiveness 
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5.  Develop  Cost  Data 

Two  of  the  main  factors  that  affect  project  costs  are  the  system 
elements  (including  support)  and  the  project  schedule.  To  provide 
accurate  estimations,  the  system  elements  must  be  broken  down  to  a 
detailed  level  and  include  the  total  life-cycle  costs.  The  schedule  will 
affect  cost  estimations  depending  on  the  demand  it  places  on  resources 
and  due  to  the  time-value  of  money. 

a.  Estimating  Tools 

Many  tools  exist  that  can  help  us  detail  both  system 
elements  and  project  schedules.  Two  of  the  more  important  tools  include 
the  Work  Breakdown  Structure  (WBS)  and  the  Program  Evaluation  and 
Review  Technique  (PERT). 

The  WBS  gives  us  a  components  view.  It  is  used  to  break 
complex  systems  down  into  subsystem  and  component  levels  that  can 
more  easily  be  evaluated.  A  simplified  example  of  a  WBS  can  be  seen  in 
Figure  22.  Each  WBS  element  represents  an  identifiable  item  of 
hardware,  software,  data  set,  or  service  [Ref.  37,  Enel.  3,  p.  2].  Each 
“level”  breaks  the  associated  WBS  element  into  smaller,  more  detailed 
elements. 
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Figure  22:  Work  Breakdown  Structure  Example 


The  PERT  assists  project  organizing  and  estimating  from  an 
activities  perspective.  This  tool  helps  us  in  the  following  areas: 

1.  Define  the  Activities.  Tasks  to  be  performed. 

2.  Define  Activity  Relationships.  Identify  predecessor/ successor 
and  lead/lag  relationships  (finish  to  start,  start  to  start,  and 
finish  to  finish)  among  tasks. 

3.  Obtain  Time  Estimates.  Estimate  the  time  (duration) 
necessary  to  perform  each  activity. 

4.  Incorporate  Eternal  Constraints.  Determine  schedule 
constraints  such  as  mandatory  completion  dates,  intermediate 
milestone  dates,  contractual  delivery  dates,  or  interfaces  with 
other  projects. 

5.  Incorporate  Resources  Data.  Apply  constraints  on  availability 
or  resources  such  as  labor,  material,  equipment,  machines,  and 
funds  to  develop  a  feasible  network  that  can  be  achieved  within 
resource  limitations. 

6.  Establish  a  Baseline  Schedule.  Assign  specific  calendar  dates 
to  activities  (and  their  resources)  and  issue  as  a  baseline  work 
plan.  Identify  activities  on  the  critical  path.  The  baseline 
schedule  must  be  consistent  with  the  technical  and  project 
baseline. 

7.  Planning  the  Schedule.  The  project  manager  should  identify 
and  schedule  near-term  tasks  (those  to  be  performed  within  12- 
18  months)  in  more  detail  and  long  term  tasks  ...  in  lesser 
detail.  [Ref.  37,  end.  3,  p.  8] 

b.  Life-Cycle  Costs 

Each  alternative’s  cost  data  must  be  based  on  its  total  life- 
cycle  costs.  As  mentioned  before,  if  a  telecommunications  network  is 
planned  correctly,  there  should  seldom  be  a  reason  to  scrap  the  whole 
thing  and  replace  it  all  at  once.  However,  the  equipment  components 
that  make  up  a  telecommunications  network  pass  through  four  stages 
during  their  life-cycle.  These  stages,  and  some  of  the  costs  associated 
with  the  stages,  are  shown  in  Table  13.  If  only  a  portion  of  a 
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telecommunications  network  is  being  replaced,  then  only  the  life-cycle 
costs  for  the  alternative  sections  need  be  compared,  including  those 
costs  which  vary  with  each  alternative  (i.e.,  support,  training,  etc.). 


Table  13:  Life-Cycle  Stages  &  Cost  Elements 


RESEARCH  & 

DEVELOPMENT 

PRODUCTION  & 

CONSTRUCTION 

OPERATIONS 

SALVAGE  & 

DISPOSAL 

*  Planning 

*  Production 

*  Personnel 

*  Inventory  Close- 

*  Management 

*  Planning 

*  Consumables 

out 

*  Engineering 

*  Management 

*  Facilities 

*  Shipping 

*  Testing 

*  Initial  Spares 

*  Support 

*  Data  Mgmt 

*  Evaluation 

*  Training 

*  Maintenance 

*  Refurbishing 

*  Equipment 

*  Support  Equip. 

*  Shipping 

*  Waste  Mgmt 

*  Facilities 

*  Manuals 

*  Technical  Data 

*  Testing 

*  Engineering 

*  Facilities 

*  Support  Facilities 

*  Initial  Transport 

*  Supply  Mgmt 

*  Modification 

*  Training 

c.  Present  Value  Costs 

To  complete  the  CEA,  all  costs  throughout  the  life-cycle  must 
be  discounted  back  to  their  present  values  in  order  to  view  the 
alternatives  on  an  equivalent  basis.  The  present  value  of  yearly  costs 
can  be  computed  using  the  equation  for  present  value,  as  shown  in 
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Equation  4.  A  discounted  rate  of  7%,  as  set  by  the  Office  of  Management 
and  Budget  (OMB)  in  Circular  No.  A-94,  should  be  used.® 


PV  =  F — - — 

(1  +  r/ 

Where,  PV  =  present  value  for  year  t 
F  =  future  value 

r  =  interest  rate 

t  =  number  of  years  from  present 

Equation  4:  Present  Value  Calculation  for  Year  t 

For  example,  to  compute  the  present  value  for  the  costs  of  a  network 
with  a  12  year  life-cycle,  Equation  5  would  be  used. 


r.  1  1  1  1 

PV  -Fi - r  +  F2 - 2  q  - FT 

Where,  PV  =  present  value  for  year  t 
F  =  future  value 
r  =  interest  rate  (0.07) 


Equation  5:  Example  Equation  for  12  Year  Life-Cycle 

While  determining  the  life-cycle  costs,  we  should  try  to  be  as 
thorough  as  possible;  however,  we  must  also  take  care  not  to  include 
redundant  costs  in  more  than  one  category. 


d.  Estimating  Pitfaiis 

Once  the  estimating  process  is  about  complete,  project 
managers,  even  seasoned  managers  with  a  few  projects  under  their  belts. 


®  This  discount  rate  was  last  updated  January,  1995.  It  is  revised  when  significant  changes  in 
interest  rates  occur. 


128 


should  take  the  time  to  review  the  estimating  process.  Hajek’s  list  of  cost 

estimating  pitfalls  to  avoid  is  shown  in  Figure  22. 

Cost  Estimating  Pitfalls 

1.  Omissions:  Was  any  significant  cost  element  forgotten?  For  instance,  are 
there  any  bench  checks  planned  and  does  the  estimate  include  the 
engineering,  material,  and  other  costs  for  such  effort? 

2.  Inaccuracy  of  the  work  breakdown:  Does  the  work  breakdown  adequately 
account  for  all  the  subsystems  and  efforts  required  of  the  device? 

3.  Misinterpretation  of  the  equipment  data  or  Junction:  Is  the  interpretation  of 
the  complexity  of  die  device  accurate?  Interpretations  leading  to  excesses 
of  complexity,  or  simplicity,  will  result  in  estimates  that  are  either  too  high 
or  too  low. 

4.  Use  of  wrong  estimating  techniques:  The  correct  estimating  techniques  must 
be  applied  to  the  device  in  question.  For  instance,  the  use  of  cost  statistics 
derived  from  production  runs  of  a  similar  subsystem  and  using  such  figures 
for  a  prototype  device  which  requires  engineering  and/or  development  will 
invariably  lead  to  excessively  low  estimates. 

5.  Failure  to  identify  and  concentrate  on  major  cost  elements:  It  has  been 
statistically  established  that  for  any  piece  of  equipment  (or  system),  20 
percent  of  the  subsystems  will  account  for  80  percent  of  the  total  cost 
(Pareto’s  Law  of  Distribution).  The  point  is  that  project  engineers  should 
concentrate  their  time  and  effort  on  the  high-cost  subsystems  in  order  to 
enhance  their  chances  for  establishing  an  accurate  cost  estimate. 

6.  Failure  to  assess  and  provide  for  risks:  By  its  nature  a  prototype  device 

involves  engineering  and  design  effort  that  must  be  breadboarded  and 
bench  tested  for  verification.  Such  tests  usually  involve  an  expenditure  of 
effort  to  redesign  and  refine. _ 


Figure  23:  Cost  Estimating  Pitfalls  [Ref  34,  p.  62] 


(i) 

6.  Risk  Assessment 

Proper  project  management  requires  that  we  evaluate  what  impact 
our  decisions  may  have  on  increasing  or  decreasing  the  chance,  or  risk, 
that  future  problems  will  occur.  This  section  will  discuss  the  different 
perspectives  of  risks,  the  elements  of  risk,  and  the  analysis  of  risk. 
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a.  The  Three  Perspectives  of  Risk 

There  are  three  perspectives  to  risk,  all  of  which  must  be 
considered  to  fully  comprehend  the  effects  an  element  of  risk  may  have 
on  a  project.  The  three  perspectives  are; 

1.  potential  magnitude  of  loss  (how  much  we  may  lose); 

2.  chance  of  loss  (probability  of  a  loss  occurring); 

3.  exposure  to  loss  (how  much  can  we  afford  to  lose).  [Ref.  38,  p. 

24] 

For  instance,  suppose  we  identify  the  schedule  for 
microwave  installation  as  containing  an  element  of  risk.  If  we  stay  with 
the  currently  planned  installation  crews,  there  is  a  chance  that  the 
schedule  could  be  affected  by  winter  weather.  If  we  increase  the  crew 
size,  project  costs  will  increase.  We  must  consider  it  from  the  three 
perspectives:  1)  how  much  time  may  we  lose?,  2)  what  chance  is  there 
the  schedule  will  be  delayed  (very  slim/very  great)?,  3)  if  the  loss  occurs, 
can  we  afford  it?  If  any  of  the  three  components  are  at  levels  that  cannot 
be  accepted,  we  must  find  a  way  to  decrease  the  risk. 

b.  The  Elements  of  Risk 

The  Defense  Management  Systems  College  Publication,  “Risk 
Management,  Concepts,  and  Guidance,”  identifies  five  elements  of  risk: 
Cost,  Schedule,  Technical  Performance,  Programmatic,  and 
Supportability.  The  first  three  are  defined  as  basic  elements.  Table  14 
contains  some  of  the  sources  for  the  five  risk  element.  Each  of  the 
applicable  elements  should  be  evaluated  using  the  three  perspectives. 

c.  Risk  Analysis 

Risk  analysis  must  be  completed  for  both  life-cycle  costs  and 
effectiveness  values. 
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During  this  phase  of  the  project  {alteiriative  selection),  the 
risks  affecting  life-cycle  costs  should  be  estimated  in  dollars  for 
comparison  purposes.  The  affects  of  these  risks  can  normally  be 
estimated  in  either  personnel  or  equipment  costs.  With  a  little  effort, 
these  can  be  culminated  into  a  final  monetary  estimation.  These  costs 
are  normally  stated  with  a  plus/ minus  percentage,  where  the  value  falls 
within  two  sigma  (95%  confidence  interval). 
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Table  14:  Sample  Risks  by  Element 
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Analyzing  risks  on  the  effectiveness  side,  and  then 
converting  them  into  monetary  values,  or  other  scaleable  values,  is  a 
different  story.  In  some  cases,  with  a  lot  of  work,  experience,  and  skill, 
this  is  may  be  possible;  however,  in  most  cases  it  is  not.  The  very  act  of 
converting  these  estimated  risk  values  into  a  single  value  suggests  a 
much  higher  level  of  accuracy  than  is  available,  suppose  an  analysis  has 
been  completed  and  the  risk  converted  into  a  value  of  $48,000  ±  20%. 
Once  given  to  the  decision-makers,  the  first  questions  asked  will  include: 

1 .  what  is  the  basis  for  these  values? 

2.  What  certainties  are  the  estimates  based  on?  What 
uncertainties? 

3.  Has  the  methodology  used  been  proven  accurate  in  the  past? 
How  accurate?  Were  the  conditions  similar? 

These  are  difficult  questions  to  answer,  let  alone  defend;  but 
if  a  decision-maker  is  going  to  make  informed  decisions  and  be  held 
accountable  for  these  decisions,  they  need  to  understand  where  the 
figures  came  from. 

Another  alternative,  as  explained  by  Dr.  James  Emery®, 
appears  to  be  much  more  appropriate,  as  well  as  convenient.  He  states 
that  if  the  decision-makers  are  going  to  make  the  decisions,  their  real 
need  is  the  information  on  which  to  base  those  decisions.  He  suggests 
documenting  the  applicable  information  in  a  concise  paragraph  form, 
along  with  the  analyst’s  perspective  of  the  situation.  In  this  manner,  the 
decision-makers  are  supplied  with  all  the  pertinent  data  and  can  decide 
for  themselves  what  the  possible  levels  of  risk  will  be. 


®  As  per  conversation  with  Professor  Emery  on  December  6,  1995. 
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7.  Cost  Effectiveness  Computations 

Once  the  effectiveness,  life-cycle  costs,  and  monetaiy  risk  values 
have  been  calculated,  a  cost-effectiveness  summary  table  can  be  formed. 
Table  15  is  an  example  of  such  a  table. 

Table  15:  Cost  Effectiveness  Summary  Table 


Alternative  #  1 

Alternative  #2 

Overall  Effectiveness 

5.0 

4.835 

Life-Cycle  Costs  ($K) 

109,148 

190,290 

Cost  Risk 

±21,830 

r  ±  47,572 

8.  Sensitivity  Analysis 

Suppose  the  analyst  has  completed  a  CEA  and  the  final  numbers 
show  alternate  “X”  to  be  the  most  cost-efficient.  To  complete  this  CEA, 
we  have  had  to  make  assumptions,  estimate  costs,  estimate  usage,  and 
make  a  host  of  other  educated  guesses,  all  of  which  affect  the  outcome  of 
the  final  numbers. 

The  purpose  of  the  sensitivity  analysis  is  to  help  us  understand 
just  how  sensitive  our  final  numbers  are  to  relatively  small  changes  in 
our  assumptions  and  estimates.  To  measure  sensitivity,  normally  only 
one  variable  is  changed  at  a  time  and  the  effects  measured  and  recorded; 
however,  if  a  variable  that  has  other  variables  dependent  on  it  is 
changed,  then  all  of  the  dependent  variable  values  should  be  changed  as 
well.  For  example,  if  “per  hour”  leased-line  charges  vary  with  usage,  then 
the  values  for  both  usage  and  “per  hour  charges”  should  be  varied  at  the 
same  time.  Sensitivity  analyses  can  be  used  to  measure  the  effects  of 
both  controllable  and  uncontrollable  input  variables. 
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With  the  advent  of  modern  spreadsheet  products,  a  sensitivity 
analysis  can  be  completed  very  quickly.  It  is  recommended  that  all  CEA 
computations  be  completed  using  a  worksheet  application. 

D.  THE  BAGS  MIGRATION 

With  the  wide  range  of  site  types,  site  locations,  site 
telecommunications  requirements,  and  the  like,  the  final  network  will 
most  likely  use  several  types  of  transmission  media.  For  example,  some 
sites  already  have  leased  lines  installed.  The  requirements  for  some  of 
these  sites  will  never  rise  above  the  service  already  provided.  Therefore, 
there  is  no  reason  to  replace  these  links  with  different  technology. 

On  the  other  hand,  some  remote  sites  now  operating  over 
microwave  require  redundancy.  Even  if  microwave  is  found  to  be  the 
most  cost-efficient  technology  for  these  sites,  a  secondary  technology  will 
likely  be  required  for  the  redundancy.  This  example  shows  the  extent  to 
which  the  standards,  applications,  and  components  chosen  must  be  kept 
vendor  and  technology-independent  for  as  long  as  possible. 

The  biggest  challenge  with  using  a  CEA  with  the  BAGS  project 
could  possibly  be  limiting  the  number  of  alternative  migration  candidates 
to  be  considered.  The  project  managers  must  find  a  method  to  limit 
candidates  without  excluding  those  that  could  end  up  being  the  best 
alternatives. 

E.  CONCLUSION 

The  CEA  is  a  very  useful  tool.  It  provides  the  organizational 
procedures  to  insure  that  our  estimations  are  as  concise  as  possible. 

One  must  remember,  however,  that  it  is  only  a  tool;  and  the  quality  of 
the  final  product  depends  as  much  on  the  craftsman  and  the  material 
(data)  used,  as  it  does  on  the  tool. 
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VIII.  SUMMARY 


Before  summarizing  the  phases  discussed  in  this  paper,  let’s 
discuss  the  last  two  phases,  “Implement  System  Plan,”  and  “Maintain 
System  Process.”  By  excluding  them  from  the  content  of  this  paper  in  no 
way  suggests  they  are  less  important  than  the  others.  In  fact,  the  first 
six  phases  only  build  the  solid  foundation  on  which  the  actual  project, 
contained  in  the  last  two  phases,  is  built. 

The  procedures  used  during  the  Implement  System  Plan  phase  will 
vary  greatly  depending  on  the  cost,  schedule,  type  of  contract,  and  many 
other  variables.  However,  if  the  previous  five  phases  have  been 
completed  judiciously,  the  project  officer  should  be  aware  of  all  the 
processes  necessary  for  a  successful  implementation.  The  last  phase, 
“Maintain  System  Process,”  adds  an  additional  dimension  in  which  the 
CG  has  not  operated  in  the  past.  There  are  two  main  themes  behind  this 
phase.  One  is  to  continue  the  migration  process,  upgrading  the 
architecture  as  necessary.  It  is  only  due  to  the  recent  advances  in 
technology  that  we  are  now  able  to  incrementally  upgrade  networks.  The 
second  theme  is  based  on  periodically  re-evaluating  the  network.  The 
TAFIM  emphasizes  that  this  should  be  done  by  reiterating  the  other  six 
phases  of  the  model. 

Although  the  procedures  in  this  paper  are  laid  out  in  a  1-2-3 
fashion,  it  should  be  understood  that  numerous  iterations  of  portions  of 
the  model  may  be  necessary  before  reaching  a  level  of  acceptance  by  all 
parties  involved.  Although  this  can  be  time  consuming  and  must  be 
limited  in  some  manner,  it  does  lead  to  a  better  designed  product. 
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The  BAGS  Replacement  Project  is  relatively  simple  from  a 
technological  view.  However,  from  a  functional  or  organizational 
perspective,  the  project  will  be  very  complex.  Gathering,  evaluating,  and 
tracking  the  functional  requirements  of  at  least  1 1  different  entities 
located  at  18  different  sites  will  not  be  easy.  This  provides  the  design 
team  with  a  great  temptation  to  aggregate  details  to  simplify  the  problem. 
By  using  the  Structured  Approach  Model,  the  design  team  will  be 
encouraged  to  view  the  project  from  various  perspectives  and  use  either 
the  procedures  suggested  in  this  paper,  or  alternative  methods  for 
tracking  and  documenting  all  the  pertinent  details. 

For  an  organization  to  become  more  efficient  and  effective  as  a 
whole,  it  must  learn  to  apply  systems  thinking.  Procedures  and  reward 
systems  must  be  changed  to  encourage  individuals  to  plan  for  efficiency 
and  effectiveness  on  the  organizational  level,  rather  than  the  department, 
division,  or  command  level. 

The  Structured  Approach  Model  is  one  method  for  applying 
systems  thinking  to  project  management.  It  ensures  that  the  project  is 
planned  on  an  organizational  level,  taking  into  account  the  requirements 
and  resources  of  all  the  entities  involved.  By  examining  each  of  the 
seven  phases  from  the  functional,  organizational,  and  physical  views,  the 
prospect  that  important  details  will  be  overlooked  greatly  decreases.  By 
investing  the  additional  time  up  front  necessary  to  apply  the  Structured 
Approach  Model,  the  project  team  will  be  steered  towards  a  network  that 
will  benefit  the  total  organization.  The  network  itself  will  be  designed  for 
greater  interoperability,  supportability,  as  well  as  cost  and  technical 
performance. 

The  Coast  Guard  must  have  an  effective,  interoperable 
telecommunications  backbone  if  its  overall  efficiency  and  effectiveness  is 
to  increase. 
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GLOSSARY 


Access  control  server  -  The  access  control  server  maintains  the 
access  control  lists  for  each  object  within  the  technical 
environment.  The  access  control  server  determines  whether  access 
to  the  requested  system  object  is  authorized. 

Applications  server  -  An  application  server  provides  a  set  of  standard 
application  services  to  clients.  It  is  a  form  of  packaging  an 
application  as  a  commonly  used  and  reusable  component  of  the 
infrastructure. 

Authentication  server  -  Validation  of  users,  nodes,  programs,  and 
other  required  objects  is  performed  through  the  authentication 
server.  Secure  channels  using  encryption  and  /  or  some  form  of 
trusted  communications  provide  the  linkage  between  client  and 
server. 

Batch  processing  -  Batch  processing  environments  are  characterized 
by  their  ability  to  queue  work  (jobs)  and  manage  the  sequencing  of 
processing  based  on  job  control  commands  and  lists  of  input  data. 
The  results  of  this  processing  include  updated  information  files  or 
databases  and  often  printed  reports  or  special  forms  that  are 
themselves  queued  as  output  jobs. 

Broadcast  -  Broadcasting  environments  provide  one-way  audio  or 
audio /video  communications  between  a  sending  location  and 
multiple  receiving  locations.  They  include  the  use  of  private  TV 
facilities  that  can  be  purchased  or  leased  for  corporate  purposes. 
Many  organizations  are  taking  advantage  of  these  facilities  and 
offsetting  travel  costs  for  use  in  corporate  announcements  and 
product  introductions. 

Communications  management  services  -  Communications 
management  services  is  another  GTE  that  is  used  by  all  of  the 
other  GTE  that  want  to  communicate.  This  environment 
implements  the  communications  infrastructure  consisting  of 
various  communication  servers,  name  and  directory  services  for 
resolving  addresses,  and  authentication  and  access  control  for 
ensuring  the  appropriate  level  of  security.  Thus,  all  the  technology 
associated  with  communications  and  connectivity  is  bundled  into 
this  environment. 
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Communications  server  -  The  communications  server  forms  the 
basis  of  managing  connections  between  objects  in  the 
environment.  It  provides  connections  between  objects  independent 
of  the  physical  implementation  of  the  network  and  ensures 
accurate  delivery  of  messages  between  objects. 

Computer  conferencing  -  Computer  conferencing  environments 
combine  the  merits  of  document  creation,  E-mail,  and 
conferencing  by  allowing  groups  and  subgroups  to  participate  in 
“conferences”  via  computer  workstation.  These  conferences, 
however,  do  not  occur  in  real  time.  The  conferees  discuss 
proposed  topics  through  interacting  over  time.  Conferees,  or 
invited  guests,  can  drop  in  or  out  of  conferences  or  subconferences 
at  will.  The  ability  to  trace  the  exchanges  is  provided. 

Conferencing  management  services  -  Conferencing  Management 
Services  supports  the  real-time  exchange  of  information  from  one 
or  more  user  clients.  It  permits  a  user  to  address  a 
communication  to  any  member  of  a  group  vidthout  needing  to  know 
exactly  who  is  in  the  group  receive  communications  from  all  or 
selected  members  of  the  group  without  needing  to  know  who  is 
currently  in  the  group,  and  to  reply  to  them  in  a  like  manner. 

Cryptographic  server  -  Encryption  services  for  any  process  are 
provided  by  the  cryptographic  server.  The  cryptographic  server 
also  manages  keys  and  handles  distribution  of  valid  keys  among 
the  cryptographic  servers.  A  centralized  key  management  server 
may  be  required. 

Data  server  -  The  data  server  provides  data  services  to  clients.  A 
client  will  send  a  request  to  a  data  server  (sometimes  called  a 
database  server)  and  the  server  will  respond  -with  the  results  of  the 
request.  The  accessing  and  updating  of  the  data  maintained  on 
the  data  server  is  performed  by  the  data  server,  not  by  the  clients. 

Database  management  services  -  Database  management  services 
consist  of  the  servers  required  for  managing  files  and  data  within 
the  technology  environment.  It  consists  of  data  servers  that 
implement  databases  and  file  servers  that  provide  local  and  remote 
access  to  various  types  of  files. 

Decision  support  -  Decision  support  environments  provide 

interactive  modeling  and  simulation  tools  that  allow  the  user  to 
analyze  the  effects  of  alternative  decisions.  These  modeling  and 
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simulation  tools  typically  work  in  conjunction  with  files  and 
databases  that  were  created  from  batch  or  transaction  processing 
environments. 

Desktop  or  Portable  Intelligent  Workstations  -  These  serve  single 
users  and  provide  personal  computing  services  and  access  to 
network(s). 

Development  services  -  Development  services  provide  support  for  all 
aspects  of  systems  delivery  including  all  phases  of  the  development 
life-cycle,  prototyping,  and  end  user  development.  This 
environment  interacts  with  the  other  GTE  to  access  information  on 
the  current  infrastructure  and  to  implement  changes  and 
enhancements . 

Directory  server  -  The  directory  server  provides  a  means  of  finding  a 
set  of  entity  attributes  based  on  qualifiers,  such  as  a  telephone 
number  or  other  descriptive  characteristic.  Unlike  a  name  server, 
the  searches  are  often  ambiguous  and  based  on  a  combination  of 
attributes. 

Distribution  management  services  -  Distribution  management 
services  support  the  distribution  of  messages,  transactions,  files, 
and  any  other  information  between  technology  environments  and 
physical  locations.  This  environment  consists  of  servers  that 
implement  electronic  mail,  voice  mail,  and  EDI.  It  also  is  tightly 
linked  to  the  communications  management  services  GTE  to 
provide  the  actual  communications  between  components. 

Divisional  or  Departmental  Processing  Systems  -  These  provide, 
primarily  local  users,  on-line  transaction  processing  services. 

Document  management  services  -  Document  management  services 
are  analogous  to  information  management  services,  providing 
other  environments  with  the  means  to  access  and  manipulate 
documents — either  text  only  or  some  combination  of  data,  text, 
voice,  graphics,  and  image  (a  compound  document).  The  key 
difference  between  these  two  technology  environments  today  is  the 
level  at  which  we  can  manipulate  basic  elements  of  information.  In 
information  management  services,  we  can  access  and  manipulate 
each  field  within  the  file  or  database.  In  document  management 
services,  we  generally  access  the  entire  file  or  document  using 
application  specific  formats  for  manipulating  portions  of  the 
document.  For  example,  the  format  for  a  Microsoft  Word 
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document  is  different  from  WordPerfect;  likewise,  the  way  graphics 
is  stored  in  each  differs. 

Document  processing  -  Document  processing  environments  extend 
the  basic  capabilities  of  text  processing  to  take  advantage  of  the 
graphics  capabilities  of  today’s  workstations  and  laser  printers. 
Consequently,  they  provide  powerful  document  and  presentation 
tools  for  the  end  user. 

Document  storage  &  retrieval  -  Document  storage  and  retrieval 
environments  are  used  to  retain  large  volumes  of  stored 
information  in  document  formats.  Originally  these  systems  were 
based  on  microfilm  media  using  film  or  fiche  with  special  readers 
to  magnify  the  information.  Computer  output  microfilm  (COM) 
systems  are  used  to  store  computer-generated  listings  or  reports. 

EDI  translation  server  -  The  EDI  translation  server  interprets  the 
content  of  EDI  messages  and  routes  them  to  the  appropriate  EDI 
partners.  The  EDI  server  works  hand  in  hand  with  the  mail  server 
but  needs  to  interpret  the  EDI  message  to  translate  it  or  route  it  to 
the  correct  recipient. 

Electronic  mail  -  Electronic  mail  environments  support  the  storage 
and  forwarding  of  directed  messages,  mail,  and  other  documents 
or  files  between  sender  and  one  or  more  recipients.  They  provide 
the  sender  with  facilities  to  create  or  define  the  message  (s)  or  file(s) 
to  be  sent,  use  directories  and  distribution  lists  for  routing 
information,  assign  priorities,  use  pre-formatted  electronic  forms, 
and  trace  the  status  of  messages  sent. 

Electronic  publishing  -  Electronic  publishing  environments  extend 
document  creation  and  production  tools  to  provide  formal 
publishing  capabilities.  This  includes  incorporation  of 
photographic  quality  images  and  color  graphics,  very  advanced 
formatting  and  style  features,  such  as  wrapping  text  around 
graphic  objects  or  pictures,  and  kerning  (overlapping  characters  to 
optimize  spacing). 

Enhanced  telephony  -  Enhanced  telephony  environments  provide 
improved  means  of  using  the  phone  system  for  interactive  audio 
exchanges  between  users.  Features  include  call  forwarding,  call 
waiting,  programmed  directories,  teleconferencing  capability, 
automatic  call  distribution  (useful  for  busy  customer  service 
areas),  and  call  detail  recording. 


141 


Enterprise  or  Corporate  Processing  Systems  -  These  serve  a  large 
base  of  networked  users  with  on-line  and  batch  processing 
services. 

Establishment-based  Switching  Systems  -  Premise-based  switching 
services  Gateways  to  WAN  Associated  servers  (e.g.,  IVR,  V-Mail). 

Ebcpert  systems  -  Expert  systems  environments  use  a  type  of  artificial 
intelligence  built  with  inference  engines  and  knowledge  or  rule 
bases  that  take  or  recommend  actions  based  on  presented 
situations  and  past  “experience.”  They  are  used  to  augment 
human  decision-making  processes  where  the  “expertise”  or 
thought  processes  of  the  decision  maker  can  be  defined  as  rules. 

PUe  server  -  The  file  server  provides  transparent  access  to  files  from 
workstations  and  other  clients.  Unlike  a  data  server,  the  file  server 
provides  access  and  linkages  to  the  file  directories  and  is  not  aware 
of  the  contents  of  the  file.  Processing  of  contents  of  a  file  needs  to 
be  performed  by  the  client.  The  file  server  does  no  client-visible 
manipulation  of  the  data  within  a  file.  Essentially,  the  file  server 
provides  the  client  with  the  use  of  a  virtual  disk  drive  and  little 
else.  For  example,  in  a  workstation  environment,  the  workstation 
would  perform  all  the  processing  on  the  file. 

Hypermedia  -  An  emerging  area  for  information  management  is 
hypermedia.  Hypermedia  provides  a  highly  flexible  way  of  linking 
objects.  Over  time,  documents,  images,  and  other  objects  could  be 
linked  in  hypermedia  databases  resulting  in  the  elimination  of 
document  management  services  as  a  separate  entity. 

Hypermedia  processing  -  Hypermedia  processing  is  a  new 
environment  that  extends  the  object-oriented  approach  to 
organizing  and  displaying  information  by  utilizing  various 
relationships  between  the  stored  or  created  objects.  As  such,  it 
overcomes  the  limitation  of  the  printed  page  and  allows  the  user  to 
“navigate”  through  the  compiled  information  based  on  mixed  form 
objects  in  a  manner  that  is  consistent  with  the  needs  and 
capabilities  of  the  user,  not  some  fixed  presentation  format. 

Inquiry  processing  -  Inquiry  processing  environments  support 

functional  area  activities  requiring  interactive  selection,  extraction, 
and  formatting  of  stored  information  from  files  and  databases. 

They  are  used  in  conjunction  with  batch  and  transaction 
processing  environments  to  provide  information  retrieval  using 
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either  structured  (routine)  or  ad  hoc  (definable)  queries.  They  are 
intended  to  replace  the  need  for  extensive  reporting  systems  by 
providing  only  needed  information  on  demand. 

Intelligent  Wide  Area  Network  Systems  -  A  WAN  system  capable  of 
providing  value-added  WAN  switching  services,  transparent  access 
to  servers,  and  WAN  management. 

Local  Area  Network  Systems  (LAN^s)-  LAN’s  connect  file  servers  and 
device  servers  and  provide  for  local  transport  and  resource 
sharing. 

Mail  server  -  The  mail  server  provides  mail  transfer  capabilities  for  a 
community  of  users.  The  basic  function  is  to  support  the  store 
and  forward  of  interpersonal  messages  between  users.  The  mail 
server  moves  messages  based  on  the  contents  of  the  message 
envelope  not  the  message’s  contents. 

Name  server  -  The  name  server  provides  a  means  of  finding  an 
attribute  of  an  entity  given  the  unique  name  for  any  entity  within 
the  technology  environment.  Entities  can  be  physical  components 
(computers,  workstations,  network  nodes),  logical  components 
(application  modules,  data  storage  locations),  or  users. 

Presentation  server  -  The  presentation  server  provides  presentation 
services  for  a  client  application  and/or  a  person.  It  creates  a 
generic  presentation  environment  that  is  independent  of  the 
underlying  technology  and  provides  a  means  for  users  to  interact 
with  the  technology  environment. 

Print  server  -  The  print  server  provides  common  printing  services  to 
clients  within  the  environment.  The  print  server  provides 
transparency  between  the  client  and  the  physical  printer.  For 
example,  differences  between  different  vendors’  laser  printers 
should  be  transparent  to  the  client. 

Real-time  control  -  Real-time  control  environments  support  event- 
driven  processes  supporting  monitoring  and  actuation  of  physical 
processes.  For  this  reason,  they  are  often  referred  to  as  sensor- 
based  systems.  They  are  designed  to  handle  and  process 
interrupts  from  a  variety  of  sources  (typically  involving  some  kind 
of  sensor  device  or  timer),  process  associated  information  through 
some  type  of  capture  or  control  algorithm,  and  respond,  if 
necessaiy,  with  an  appropriate  signal  to  a  control  or  actuation 
device. 
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Repositories  for  system  construction  -  A  passive  repositoiy,  such 
as  those  being  introduced  by  IBM,  DEC,  and  others,  can  provide 
the  dictionaries  and  system  encyclopedias  needed  for  defining  and 
constructing  application  systems  and  data.  This  type  of  repository 
is  the  essential  underpinning  of  a  CASE  environment,  as  it 
provides  the  basis  for  storing  information  at  each  phase  in  the 
development  cycle  and  transferring  that  information  from  one 
phase  to  another. 

Repositories  for  systems  management  -  Another  type  of  repository, 
called  the  active  repositoiy,  can  be  used  to  store  system 
information  and  to  dynamically  manage  the  IT  environment.  For 
example,  with  the  capabilities  of  an  active  repository,  system 
management  services  could  manage  the  execution  of  applications 
to  optimize  performance  and  reliability. 

Repository  services  -  Repositoiy  services  is  an  emerging  GTE  that 
will  provide  the  repository  environment  for  managing  the 
technology  environment  and  the  applications  and  data  stored  in 
the  environment.  The  repositoiy  can  store  information  about  any 
“object”  in  the  technology  environment  including,  but  not  limited 
to,  the  physical  processors,  application  modules,  data,  and 
processing  functions.  All  of  the  GAE,  GTE,  components,  and 
servers  defined  in  this  document  would  be  entities  in  a  repository. 

Sensor  monitor/ actuator  server  -  The  sensor  monitor/ actuator 
server  provides  client  applications  and  users  with  an  interface  to 
physical  devices  such  as  cash  dispensers,  building  monitoring 
systems,  or  any  other  device  that  interacts  with  physical  control 
systems. 

Shared  screen  teleconferencing  -  Shared  screen  teleconferencing 
environments  are  another  newly  emerging  type  of  system  aimed  at 
supporting  more  effective  remote  communications  in  an  interactive 
mode  between  two  or  more  users.  They  combine  an  audio 
teleconferencing  capability  with  shared  common  workstation 
“windows”  that  are  refreshed  on  every  conferee’s  workstation 
whenever  someone  displays  new  material  or  changes  an  existing 
display. 

System  management  services  -  System  management  services 
support  all  activities  dealing  with  the  management  of  the 
computing  environment,  interacting  with  all  other  GTE  to  provide 
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the  management  capability  to  monitor  and  control  the  total 
environment. 

«‘T**  or  ‘‘t’*  -  Designation  used  to  represent  the  Coast  Guard’s 

Command,  Control,  and  Communications  community.  Capital  t 
represents  headquarters  staff,  while  the  small  t  represents  “f” 
personnel  assigned  to  other  commands. 

Text  processing  -  Text  processing  environments  support  the  creation 
of  text  documents.  They  have  evolved  from  the  early  word 
processing  systems  of  the  seventies  to  be  popularized  as  part  of  the 
explosive  application  growth  of  desktop  personal  computers.  They 
offer  greatly  improved  editing  and  revision  capabilities  over  the 
typewriters  that  they  were  designed  to  replace. 

Time  server  -  A  critical  need  in  distributed  environments  is  to  make 
sure  that  time  is  S5mchronized  throughout  the  environment.  This 
is  especially  important  in  distributed  transaction  processing 
applications  and  database  environments  where  logs  need  to  be 
kept  synchronized  to  support  transaction  backout  and  recovery. 

Transaction  media  services  -  Transaction  management  services 
implement  the  environment  required  for  managing  transaction 
processing.  This  environment  includes  the  basic  functionality  and 
servers  required  to  implement  a  transaction  processing 
application.  In  today’s  world,  CICS  would  fit  under  transaction 
management  services.  In  the  future,  it  is  anticipated  that  a 
client/server  environment  will  become  the  norm. 

Transaction  processing  -  Transaction  processing  environments 
support  on-line  capture  and  processing  of  information  in  an 
interactive  exchange  with  the  user.  These  typically  involve 
predetermined  sequences  of  data  entry,  validation,  display,  and 
update  or  inquiry  against  a  file  or  database. 

User  interface  services  -  User  interface  services  provide  the  basic 
means  for  users  to  interact  with  the  computing  environment, 
mainaging  the  user  interface  for  any  class  of  user  interface  device 
from  a  simple  character  terminal  to  an  advanced  graphic 
workstation.  User  interface  services  also  provide  support  for  the 
user  in  navigating  through  to  the  appropriate  system  or  server, 
authenticating  the  user  and  managing  the  user’s  desktop. 

Video  processing  -  Video  processing  environments  support  the 
creation  of  video  “productions,”  either  as  sequential  presentations 
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or  as  interactive  presentations,  under  user  control.  They  involve 
both  video  and  sound  capture  and  editing,  as  well  as  incorporating 
still  graphics  and  title  generation  capabilities. 

Video  teleconferencing  -  Video  teleconferencing  extends  the  remote 
meeting  environment  to  include  full  motion  display  of  events  and 
participants  in  a  bi-directional  manner.  Thus,  the  facial 
expressions  and  body  language  of  presenters  and  questioners  is 
displayable  to  all  participants  in  a  conference. 

Voice  mail  -  Voice  mail  environments  offer  the  storage  and 

forwarding  of  voice  messages  for  a  designated  set  of  recipients. 
They  are  usuaJly  used  as  an  extension  of  the  phone  system  to 
provide  an  alternate  to  message  centers.  They  typically  allow  the 
recipient  to  retrieve  recorded  messages  remotely  from  any  touch- 
tone  telephone. 
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